Peter,
Unless I completely misunderstand what you're saying, the
tag-promotion idea is a very bad idea in all but the most simple
projects. It falls apart as soon as (following your example) the two
engineers have competing changes made to the same file. Either
they'll have to reconcile the versions (ie, do a merge) or one will
overwrite the other's changes blindly (not so good).
On the other hand, if you're maintaining a hotfix tag off of a
general service branch for important standalone files, subversion can
do that too. I just don't see that it's a very good idea.
On 10/31/06, Peter Kahn <citizenkahn@gmail.com> wrote:
>
> - Where do you weigh-in on these two methods (tag-promotions v.
> branch-merge)?
> - Was the decision to not have tags in subversion related to tag-promotion
> in some way?
>
>
> I just ran across a project that used multiple cvs tags to provide for
> concurrent development on a single branch with out merging. SVN wouldn't
> support such a thing and I'm wondering what you think of the consequences
> between tag-promotion and branch-merge models for concurrent development.
> Below, I explain my view of the two methods and provide examples.
>
> I have anxiety over the tag-promotion model, but I'm unsure if it is because
> it is inherently more risky or because its unfamiliar to me. I think that
> it is possible for both to have identical risk because both involve the
> eventual combination of changes between multiple projects. Branch-merge
> manages the combination in a highly structured way, but has extra effort
> associated with it. The tag-promotion method seems like it has less
> structure, but also less effort.
>
>
>
> Tag-promotion:
> I have a branch on which I'm working on an emergency hotfix and a service
> release.
> I have a tag called hotfix
> engineer A, modifies code and updates the hotfix tag to include the
> modification versions
> engineer B, modifies code
>
> I build from tip/HEAD for my service release build
> I build from hotfix tag for my hotfix build
>
> Result, concurrent development with no merging.
> Problems: If A's change relies on code that's on the branch but not in the
> hotfix label I can have a problem building (bad) or a bug a runtime (really
> bad)
>
> Branch-Merge
> I have a main/trunk, a branch for the hotfix and a branch for the service
> release
> engineer A modifies files on the hotfix branch
> engineer A merges the files to the service release branch
> engineer A merges the files to the main/trunk
> engineer B modifies files on the service release branch
> engineer B merges the files on the service release branch
>
> 2 changes = 3 merges with each merge taking up engineering time and adding
> risk...
>
>
>
>
> I look forward to hearing from people regarding these two methods of
> concurrent development. Thanks.
>
>
>
>
> --
> Peter Kahn
> citizenkahn@gmail.com
> citizenkahn@jabber80.com, pkahnpie1@AIM, skype: citizenkahn
> http://analogoustendencies.blogspot.com/
> Awareness - Intention - Action
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 3 03:59:23 2006