By now you’ve probably heard about workspace reparenting in AccuRev. You know… the fancy drag-n-drop of a workspace from one stream to another. But what’s all the hype? Ultimately, workspace reparenting means that a workspace, on disk, can ‘morph’ into the configuration of it’s parent stream (See video) . So one day you are working on a mainline feature and the next day, with a single command, you can instantly have the configuration from a buggy release 2 months ago on disk, in the same location, with the exact configuration of files at that point in time. Poof! 
Well… first off, reparenting isn’t magic. You see, each and every stream in AccuRev knows at least two things – (1) its parent stream and (2) any active changes to its own relative configuration. Knowledge of the parent stream is by way of reference, in the same way that an OO subclass knows of its parent class. So if you change the parent reference, you instantly have visibility into the new parent configuration, in combination with any active changes that come along for the ride (as needed, most likely). Remember, workspaces are streams too!
Fun Toy or Power Tool?
The only “fun toy” you’ll find in AccuRev is the easter egg hidden in Help–>About where if you press CapsLock-Pause with your left hand you can play a tetris clone… ok, kidding. Workspace reparenting is a wickedly powerful feature that, when used properly, can save time, energy, and disk space and be a great powertool. So when is reparenting useful?
Retargeting a Delivery – Remember the time when you spent Saturday night cranking out a hot-fix… only for it to be reclassified to a lower priority on Monday and scheduled for next weeks build? No problem! Simply reparent your workspace from the release hotfix stream to the mainline area and promote the changes. done. go home.
Large Code Footprints – Lets say you have a 400Gb footprint of source code for any given release. On a particular day, you just finished committing 174 source files to mainline for a new feature. You then get tasked to the bug squad to tackle 9 high-priority bugs found in the recent production release. Rather than creating a brand new workspace from the old release snapshot, you can simply reparent your ‘mainline’ workspace and run update. You’ll most likely get the old versions of 174 files and probably a few dozen or hundred other files that changed… but the point is, you just get the delta. And waiting for 2G of changes over the wire compared to 400G is a significant time savings for you and others sharing the pipe.
Tracing Defects - You know those bugs that crop up and someone asks, “how long has that runtime defect been around?” Take a single workspace, create a unit test that forces the failure, then reparent to each and every release snapshot in question. Each time you do an update, you’ll get a corresponding configuration of code on disk -and- the tweaked unit test (active changes come along for the ride, remember!). Run the test, verify the failure. Bingo – a recipe to quickly test how far back a defect went. Just keep reparenting and running the test(s) until you find a configuration that works.
Rapid Application Development – Are you responsible for cranking out a few features all at once? Need to hop between them frequently? Sure, you could create a separate workspace for each feature and that’s probably a better practice in most cases… but nothing stops you from using a single workspace and context-switching by reparenting. As long as you keep/promote each feature’s set of files out of the workspace, then reparenting is a breeze. This works well if you follow a stream-per-feature paradigm.
So now you might say, “But isn’t reparenting the same as updating my local work area with a different ‘branch’?” Nope. Don’t forget about the most significant architectural difference between streams and branches… inheritance. We’ll save that for another thread.
One of the great things about workspaces is that they are a super tiny meta-data record in the AccuRev meta-database… just a pointer to parent stream and pointer to host machine and dir on disk. That’s it. Workspaces are cheap entities. Reparenting simply changes the single parent reference reference and updating only retrieves the deltas. Make reparenting part of your routine and the benefits will follow.
/happy reparenting/ – dave
We have used this feature a bit at DeLorme. One important caveat, not mentioned in the post, is that running ‘accurev update’ after moving a workspace is very important to ensuring a match between the new parent stream and in the child stream. If you forget this step the results can be somewhat confusing.
This very small wrinkle aside, I suspect you will find that workspace moves will steadily increase in value as you fully integrate with the power of AccuRev.
-christian
Hey Christian –
Thanks for pointing out the requirement to do an ‘update’ after reparenting – it is important! The great thing about requiring the update is that if you reparent to the wrong stream, you can simply reparent again to the correct stream and the workspace is none the wiser (though, the stream history *is* tracked internally). I’ve had folks jump the gun and say running update was an unnecessary extra step. Though, the counter example is imagine accidentally reparenting to a stream with 2G or a completely undesired configuration of source code… while no damage would be done, you’d be waiting for the code to go on disk.
As a side note, I’ve used a few lines of regex in my custom triggers to easily configure who can reparent where in the stream hierarchy. For example, all workspaces can reparent (chstream) to streams ending with “*_int”, “*_dev”, or “*_hotfix”. It all depends on your naming convention, but it’s an easy way to control reparenting!
Reparenting streams in the GUI is easy. Too easy. I really wish there was a way to disable that, because we almost never want to do so. That and better auditing – the current “chstream” entry in the workspace’s history only says there was a change, not what the stream was before and/or after the change.
Hey Ross –
I definitely agree that reparenting streams is sometimes too easy. Though, we have customers on both sides of the fence; as in your case, when the stream structure is well defined everyone knows where to work and reparenting is not a valid chess move. On the other side, folks with remote teams or developers juggling many projects may reparent frequently to new codelines or projects (configurations).
In your case, I’d suggest setting locks and/or ACLs on your streams, especially the workflow-centric ones (i.e. Integration, QA, Prod). Both can be done from the StreamBrowser. Locks are the easiest to set and control both promotion -and- reparenting. ACLs allow more fine-grained control of content access as well as reparenting.
Let me know if that helps! – dave