More questions on branching

[George Mills]

Is there an alternative way of retrieving branches other than having different build scripts for every combination of branches.

About the only thing I like in cvs (and I do mean the only thing) is it's branch retrieval mechanism, which can be confusing but it does not require to edit build scripts.

The only way I can see doing this with Vault (and what we did with VSS) is if someone want to work on a branch they have to override their working directory for the branch. But to do this they have to override the trunk part of the tree to something they do not want in the build and then override the branch to the original name. This is slightly tediuous and error prone. Does Vault supply any help over VSS here?

Example:

MainProject->SubComponent
Build Script Builds MainProject->SubComponent

Now Branch SubComponent

MainProject->SubComponent
MainProject->SubComponent_V2
Build Script Still Builds MainProject->SubComponent

Everything still inherits working folders from MainProject
Now override Working Folders

MainProject->SubComponent map to C:\MainProject\SubComponentTrunk
MainProject->SubComponent_V2 map to C:\MainProject\SubComponent
Unchanged Build Script Now Builds MainProject->SubComponent_V2

Assume in the example I'm using NAnt or something to build to avoid the GUID problems in .xxproj files which complicate things further.

Do most folks alter build scripts to handle branches or override working folders?

Thanks

[ericsink]

You can use the -destpath argument on the command-line client to specify where the files should be placed. This is better for a build script anyway, since I don't think you really want a working folder. When Vault is asked to "get" files to a place that is not the working folder, it merely gets the files but does not create state information and bookkeeping in anticipation of a checkin.

Please let me know if I have somehow misunderstood the question.

[George Mills]

I don't understand how that solves it. Yes that might work to solve the build (and again custom scripts for each brabch scenerio).

But how does that work for the developers. Some developers will work on the trunk and some will work on the branch. (i.e. check in).

[ericsink]

Is there an alternative way of retrieving branches other than having different build scripts for every combination of branches.

Let's back to the original problem. You believe that you need "different build scripts for every combination of branches". Could you tell me exactly why?

The phrasing of this question made me believe that you were talking about automated builds with the command-line client. Your latest reply sounds more like the issue is developer workflow.

I want to understand the problem before I make another guess at what the solution is.

[George Mills]

It's both, developers and automated builds.

The reason is on VSS/Vault a branch forces a new project folder name to put the branch in.

That means scripts higher up in the tree must be changed to use the new branched folder name. Or each user must use clever working folder overrides to fool the build scripts.

In cvs (I'm no fan of cvs, but this is one of the few things it does well) you just say check out the tree with the branch and everything is it's orginal place. No build script changes, no working folder overrides. They just need to know the branch to check out.

Now this is excluding the whole issue around direct references held in .xxproj files.

[ericsink]

Yep, there are two common ways of doing branches. For tools like VSS and Vault and Perforce and Subversion, the branch shows up as a folder in the normal hierarchy.

A lot of older tools handle it differently. CVS and PVCS are examples.

People tend to have strong personal preferences about this. If you prefer the CVS approach, Vault may seem a bit odd.

[Guest]

Ok, now that we got that clear. Back to my original question.

> Do most folks alter build scripts to handle branches or override working folders?