RE: Branched and non-branched work flows?

> I have a situation here where one developer prefers avoiding branching
> code (from release version 1 of software to v2), when possible because
> he finds branches a time-waste, due to workflow overhead when trying
> to make the same change to both the released v1 and the unreleased v2.

How then does he keep them separate? If he makes a code change that needs to be in both how do you build release 1 and release 2 from the same folder structure?

> And another developer prefers branching code from v1 to v2 ahead of
> time, "just in case", that something will change, and because he
> prefers to "think about" the two versions as separate code bases.

Well, they are two separate code bases. V2 is "based" on V1 but it does diverge.

> So... what's the best way to go ahead? Assuming we want fast
> development times.
>
> 1) Branch the code anyhow, and make the workflow slower for developer 1?

There are a many thoughts on this. Branch for release or use feature branches (branch for the new version).

You of course don't have to branch in advance. If you find you need to modify V1 you can create a v1 branch any time from the revision where you released version 1 (which I hope is tagged).

I'm still not sure with dev 1 how having a branch for ver1 slows him down? He can do his work in trunk, check it in as a single rev and if that needs to be in v1 also merge that rev into the v1 branch.

> 2) Revert to non-branched mode, because it's faster and we have no
> need for any file to be branched, and tell developer 2 that he is
> being "precious" with his way of seeing things?

I still think this dev is doing "something" to keep them separate. I am confused as to how you could build v1 from trunk if you are committing v2 changes.

Of course, a lot of this depends on how much change is happening from v1 to v2.... is this a minor point release or a major release.

> The situation is that both developers are pretty firmly "dug in" to
> their way of working and convincing either to change their way of
> working may be harder than finding something that works for both.

Subversion is pretty flexible... the probably here sounds like you have to people using (wanting to use) different methods. They have to agree to follow the same source control patterns no matter how they choose to do it.

I would still want more info from dev1 that doesn't "like" branches. What pain points is he talking about? How does he keep the code separate when he builds each release if they are just all in the same folder? Does he understand how merging works in svn 1.5+ and how to cherry pick. Have these devs read the svn book to understand the different branch work flow patterns that it describes?

BOb

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357734

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-01 21:01:26 CEST