On Wed, Jun 17, 2009 at 10:49:38AM +0530, Chintana Wilamuna wrote:
> On Tue, Jun 16, 2009 at 9:40 PM, Tyler Roscoe<tyler_at_cryptio.net> wrote:
> Auto merge all commits to a branch to the trunk of a project. So the
> idea is to keep the branch and trunk in sync, taking off the merging
> responsibility from developers.
If all commits from the branch go to the trunk, what is the branch for?
This feels like a "we cut our release branch too early" scenario -- been
there!
> > How do you propose to handle merge conflicts or other non-standard
> > results, especially without a working copy?
>
> Yes Tyler, I know the inherent problems with it but this has been
> decided based on two assumptions.
>
> 1. Probability of a conflict is low.
> 2. Cost of a conflict is low than the cost of not getting a commit
> that does not conflict to the trunk.
No I mean, technically, how do you propose to handle those situations?
How should subversion (or your scripts or whatever) behave? Drop bad
commits on the floor? What to do with the next commit? Go ahead and
apply it?
I don't have good answers for those questions, and my hunch is that this
is why subversion makes you do merges into a working copy.
If you really have to do this, I would suggest just having a working
copy that your script updates, merges into, and commits from. It can
alert you if there is a conflict and a human can investigate before
anything crazy happens (e.g. a commit is dropped due to conflicts but
later commits attempt to go through anyway).
hth,
tyler
Received on 2009-06-17 07:43:05 CEST