On Mon, Jun 1, 2009 at 19:39, Theodore H. Smith <delete_at_elfdata.com> wrote:
> Hi everyone,
>
> 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.
>
> 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.
>
> The situation for both developers (working on the same product), is
> that right now there are no branched files or files we can for sure
> foresee that it will need branching. In fact for all the work I can
> forsee that there will be no need to branch any files. The only
> problem we can forsee are having to disable features for v2 that
> shouldn't be accessed yet from v1.
>
> 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?
>
> 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?
>
> 3) Something else? Can we have both branched and non-branched working
> directorys? Or is that simply an impossible thing?
>
> 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.
>
> Ideas anyone? feel free to give your opinions even if it's not so much
> "here is a technical solution" but more "well here is a personal
> solution to get one (or both) to have a different attitude."
Yes, there is some (workflow, cognitive, organizational, ...) overhead
to using a release branch, versus just dumping everything on trunk and
releasing from there. If you have a very sequential development
process, where you are absolutely sure you'll never commit bug fixes
for version N *after* you've committed features for version N+1, then
you don't need branches.
That said, I imagine there are few projects that really fit that
description. You're almost always stuck maintaining at least version
N, while you work on N+1.
Here's how we do it:
Let's assume we're about to release version 9.1.0 of our product.
We pull a release branch (named "9.1" from trunk as late as possible,
but before any changes not relevant to that release go into trunk.
(This works well enough since we work iteratively and know what the
tasks for the coming iteration are.)
- At this point, trunk is -- in essence -- the development branch for "9.2".
- On the branch "9.1", we are preparing for the release "9.1.0".
- Only fixes intended to be included in "9.1.0" go into the this branch.
- Commits to "9.1" are generally merged to trunk.
- Changes to trunk are not merged to "9.1".
- At some point, we make a release, from branch "9.1", tagging it as "9.1.0".
- Now branch "9.1" is the release branch for 9.1.1
(Lather, rinse, repeat)
- When trunk is nearing 9.2 release, pull a branch "9.2".
- Trunk becomes development for "9.3".
- The branch "9.1" is generally discarded shortly after 9.2.0 has been tagged.
I said above that you could avoid the need for a branch if you could
guarantee a that your commits are ordered such that changes for N+1
never get committed before changes for N. Well, that same constraint
applies to our release branch "9.1" in this example. We have to be
careful not to commit changes for 9.1.1 before 9.1.0 is out the door.
Since the changes made on such a maintenance branch tend to be small
and controlled, this has never been a problem. If it were, we would
follow the same pattern, and pull a "9.1.0" release branch from "9.1"
before the first change destined for "9.1.1" was committed. (You
could, of course, pull such a branch "after the fact", in case of an
oopsie!)
As to what to do: (On the assumption that you have a situation similar
to ours, where you actually need a release branch.)
--> Teach developer (1) how to use merge.
// ben
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2357739
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-01 21:04:20 CEST