Sketch with Dropbox and multiple users - dropbox

I am using Bohemian Coding Sketch to design websites. All my files are in Dropbox, shared with a team (another designer). Most of the time we are working together with same files — one is editing, another is watching and discussing. I think this is a pretty common scenario these days.
When files are changed by the other, they get changed on my disk by Dropbox. And after that things go worse. Sketch gives this warning:
Any choice I make is bad, because:
Revert changes. It does not mean "revert to a file on disk". It actually means "revert to a file state, that was when you last opened the file".
Save. Means "overwrite with your changes work from other designer".
Cancel. Means "Do nothing"
Since this dialog opens when I close the Sketch, I have no option, but to shoot myself in a foot.
Does someone have a solution? One proposed is to copy files from shared folders to view them, which works but smells funky...

Ok. So this is a workflow issue. Sketch doesn't have or offer the ability of multiple user versioning. So it's a highly bad idea for more than one person to be working on the same file.
You're two choices are...
Have the other artist create a duplicate file. Not only does this insure proper versioning (something you guys should be keeping track of), but it also allows for the lead to then take the best ideas from each and combine them into a new versioned file.
Purchase an asset management system like AlienBrain. It handles a lot of the tedious processes of versioning for multiple artists in a studio. However I'm not aware of its integration with DropBox.

Related

In Ektron, Load Last Active Location

Question:
Anyone know what setting in my user profile will make Ektron always load the last active work area location? If not, is there a way to load a specific folder every time?
Already Tried:
"Set smart desktop as the start location in the workarea." doesn't seem to do anything.
Why:
I'm primarily a designer, so I'm usually just replacing files in the library and leaving the content area to the developers. It's kind of annoying that the content area always loads first because the folder structure looks the same and many times I actually navigate to the content folder instead of the library folder. This is a waste of time because Ektron is so slow. It would be really helpful to load the last active location in the area or at least the library files first.
Thanks!
The short answer is no. At least, not in any way that would be supported by Ektron or be upgrade-safe (upgrades would likely destroy changes made to include this functionality).
The long answer is that the Workarea code source is available and a .NET developer who wanted to parse through it and figure it out would probably be able to do so. It would require adding a user property / cookie to store their last activity (at the desired level of specificity) and then update any and all related code files that would automatically take them to any given recorded location. It would be inadvisable due to the effort required and for the upgrade-related reasoning above.
THAT BEING SAID - Ektron's Workarea uses Frames and you may be able to bookmark one of those internal frames or else create your own set of frames in your own HTML that would load up the view that you want. Depends on whether it's important enough to you to put in the effort to figure those things out by inspecting enough of the client-side code.

Exchanging work before accurev promote

My colleague and I are participating in a huge project located in Accurev. We've already created own workspaces backed with some stream (let's call it zzz-stream) which is used by many other participants, not only by us.
The point is that we want to exchange our work between our workspaces, make some changes, exchange again, etc. BEFORE making the changes accessible for others, i.e. in other words we don't want to propagate our changes until it is stable and tested, but we want be able to work on it together.
My idea was to create new stream (yyy-stream) backed with zzz-stream, and then change our workspaces to be backed with yyy-stream. But unfortunately I have no rights to create streams.
My second idea was to use a workspace as backed stream, but it doesn't work because Accurev can't use ws as backed stream.
Is there any solution for our problem?
UPD: I accepted Brad's answer as most detailed. However Accurev is too heavy and sluggish to be used effectively. So actually I prefer to use Git for internal needs over the accurev workspace. (see Accurev externally, git internally)
Your idea of creating the yyy-stream is the EXACT right way to do it. The other options are decent workarounds for one-off situations, but creating the extra stream is simple and is fully leveraging AccuRev's capabilities.
That being said, I understand that your admins have stream creation locked down. They of course want control, but should be allowing for maximizing developer productivity and not forcing workarounds like this. My guess is they have stream creation locked down to a particular group being enforced by the server-admin trigger. One common thing I have seen other large sites do is:
- allow streams to be freely created off of a list of acceptable streams (easy to do in the trigger)
- enforce naming rules on the stream creation. This is important to admins in large sites to keep things organized. Again, this is very easy to enforce via the server-admin trigger.
Bottom line, if this is a common situation, work with the admins to allow this capability as per the above. If they have any questions, they are more than welcome to contact AccuRev and we will help them out.
Your idea on using another stream for you and your peer is a good one and is commonly called a collaboration stream. If your site has stream creation locked down, you would need to work with your AccuRev administrator to make that happen.
Another option is for you and the other developer to pull the keeps from the other workspace into your own stream. This relies on both of you being diligent about doing keeps and then you can look at the history of the other developer's workspace to find the keep operation, right-click that transaction and then select Send to Workspace. The destination workspace must be your own.
A third option (more for a situation where you are in your workspace and know exactly what file you want to grab the other users changes)is to bring up the version browser for the file, right click and select history/browse versions. Look for the other workspace, highlight the version in that workspace, right click and select send to workspace. This will checkout that version into your workspace.
This is similar to the change palette suggestion but quicker if your looking to this on a file basis.
Another idea is to use different version control system (e.g. git or svn) over Accurev workspace to exchange the changes and keep our history separated from zzz-stream. (similar to Accurev externally, git internally) Only changed files should be added to other VCS, not whole project. Some merge problems occur though.

How can I prevent perforce from opening / moving deleted files?

Hello helpful persons,
I'm working with trying to set up some new branch structures in our companies codebase for organization and sanity purposes. True to form decision makers have changed their minds and want the structure to be changed a bit from what I already have in place. Not an over-the-top request though, because no one is yet using the new structure so I have "free reign".
I need to simply move these thousands of files in the containing branch directories (//depot/main/... and //depot/dev/... respectively) into a //depot/main/[product_name]/... structure etc. which I'm on board with and understand the advantages.
While opening the files from //depot/main/... for edit and move I see in my output that there are several warning messages:
warning: edit of deleted file
and
warning: move of deleted file
How can I tell perforce that I do not want to open deleted files for edit, and in turn that I do not want to move deleted files to the new location(s)?
I have a feeling that there is some documentation that I am either not understanding or not finding properly.
Generally you only get that particular warning if you aren't synced to head and are trying to move a file. Make sure you are synced to the head revisions.
As suggested by raven you should probably be using integrate for this. Generally my recommendation is to use 'p4edit/p4 move' intra-branch and 'p4 populate/integ/copy/merge' for interbranch branch integrations.

Application Scope settings or something else

I am in the process of building a completely fresh version of an application that has been in existence for a good many years. I can look back with horror now at some of the things I had done, but the whole point of life is to learn as we go along. The nice thing now is that I have a clean slate from which to work, and it's because of that that I thought that I would seek some advice from you all.
User settings are great for those things that each individual user would naturally want to and ought to be able to change, a theme or visual style for example. Application settings should quite obviously apply to the entire application irrespective of whoever uses it.
Somewhere in the middle though are a set of settings that I would like to give the system administrator the opportunity to change (default work periods, appointment time slots, the currency the company wants to use as its main trading one etc etc). These can't be user settings because individual users should not be able to change them, nor should they be application settings because I as the developer have no idea what the end user (or to be more exact the senior end user) would want to set them to.
Many years ago I might have considered writing such settings to the registry, or an ini file. I could perhaps (as this is an application that is tightly integrated with its own custom database) create a one off settings table, and read in the relevant settings at program startup. I could perhaps opt for a separate 'universal settings' xml configuration file stored in the all users directory. Clearly a number of options.
What I would like to try and establish though is the most efficient way to approach this. What is the best trade off between file read and write operations as against reading everything into a set of public constants at application start-up? These are not going to be settings that will only be referred to occasionally so efficiency is going to be key.
Just so that there is no ambiguity as to what the application will be. Traditional winforms, using vs 2012 as the development ide and vb.net as the code base based on .net4.5 and ef 5.0. Backend data to be stored in either sql express or full sql server. Target operating system for end users will be windows 7 or above (so due respect for the uac will be required).
I'd welcome any suggestions that you might have.

Creating a test site for updating a CMS

I have been asked by a client to make amends to their site using the custom CS system that was built for them (by somebody else). Making the changes is not a problem but they want the changed to be viewed on a test server before going live and the only way I can think of doing that is by pulling the entire site down, duplicating and reconnecting databases and uploading it to a test server. Then I would have to make all the changes twice which isn't really ideal.
Does anyone know of a way to do this that isn't such a ball ache? There's hundreds of files and data tables as you would expect with a custom CMS and for changes that would only take a few hours to do duplicating the entire site seems a tad unnecessary.
Cheers,
Sam
Does the CMS have "preview mode"?
Typically, in a CMS you make your changes using the content editing interface, save the changes, allow authorized users to view the changes in preview mode, and then change the status to "approved"; this then sends the changes live.
Different products call this by a different name, and have different ways of doing it - but it's worth rooting around in the custom CMS to see if there's something similar.