Comments on: Reparenting Workspaces – What's the hype?

By: Are ClearCase Dynamic Views Still Necessary? « Software Configuration Management

Wed, 11 Mar 2009 18:00:58 +0000

[...] a full checkout of everything just to modify 1 line of code in 1 file. With AccuRev, you can simply re-parent one of your workspaces, update, check in your [...]

By: Pattern for Continuous Builds « Software Configuration Management

Pattern for Continuous Builds « Software Configuration Management — Wed, 05 Mar 2008 20:51:23 +0000

[...] valuable work such as comparing builds or serving as temporary baselines for developers who want to reparent. As you can see in the stream structure, AccuRev stores both active and inactive snapshots and it is [...]

By: davidpthomas

davidpthomas — Fri, 05 Oct 2007 17:41:21 +0000

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

By: Ross Patterson

Ross Patterson — Thu, 04 Oct 2007 15:38:43 +0000

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.

By: davidpthomas

davidpthomas — Mon, 24 Sep 2007 15:58:59 +0000

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!

By: Christian Ratliff

Christian Ratliff — Mon, 24 Sep 2007 13:47:42 +0000

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