You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "pobox@verysmall.org" <po...@verysmall.org> on 2008/02/08 10:55:32 UTC

the truth about merge tracking

Correct me, if I am wrong, but there seems to be a bit of a hype around 
the merge tracking, which, if resolved, would make the life of people, 
who just start to get involved with the issue, easier.

Here is example -

The svn book describes how merge should be done, recording data about 
the merged branches in the commit message.

The Svnmerge.py wiki, however, says in the FAQ - "Merging the same 
change twice isn't usually a problem. It's a problem in two situations: 
a) if you don't want a certain change, and b) If your trunk and your 
branch are both diverging". Which means that in all other cases merging 
all again and again should not be a problem.

So basically the svn book tells only half of the truth. I think, if this 
is corrected, many new users will feel relieved.

Also, related to this, and with all due respect for the author of the 
svn book - but my feeling is that it has an extremely negative style. I 
can understand the need to warn people, but if it is cleaned up from all 
potential dangers and simply tells HOW things should be done, instead of 
mentioning all possible disasters one can end up in - it would read much 
nicer. Honestly, after reading for about 1-2 hours one day, I almost got 
headache and started to wonder why am I trying to use subversion if it 
is full with traps and possible disasters :)

Regards,
Iv

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: the truth about merge tracking

Posted by "Bicking, David (HHoldings, IT)" <Da...@thehartford.com>.
> -----Original Message-----
> From: pobox@verysmall.org [mailto:pobox@verysmall.org] 

> Correct me, if I am wrong, but there seems to be a bit of a 
> hype around the merge tracking, which, if resolved, would 
> make the life of people, who just start to get involved with 
> the issue, easier.

I don't see hype, but this is a subjective observation.

> 
> Here is example -
> 
> The svn book describes how merge should be done, recording 
> data about the merged branches in the commit message.

This is the situation without merge tracking, which becomes available in
1.5.  However, currently, there is a nice script that gives us merge
tracking before then...

> 
> The Svnmerge.py wiki, however, says in the FAQ - "Merging the 
> same change twice isn't usually a problem. It's a problem in 
> two situations: 
> a) if you don't want a certain change, and b) If your trunk 
> and your branch are both diverging". Which means that in all 
> other cases merging all again and again should not be a problem.

... Which is this script.  Svnmerge supplies merge tracking, and the
documentation is saying that because of the feature, you _rarely_ have
to worry about re-merging the same changes.  Subversion 1.5 supplies
these features and then some more (migration will be supplied with the
upgrade)

> 
> So basically the svn book tells only half of the truth. I 
> think, if this is corrected, many new users will feel relieved.
> 

It tells you the whole truth, excluding third-party addons, for
Subversion 1.4.

> Also, related to this, and with all due respect for the 
> author of the svn book - but my feeling is that it has an 
> extremely negative style. I can understand the need to warn 
> people, but if it is cleaned up from all potential dangers 
> and simply tells HOW things should be done, instead of 

I understand your point.  However, open-source projects tend to be all
about giving maximum flexibility and freedom of choice.  With that in
mind, it makes sense to point out the pit-falls clearly.  Essentially, I
view this as saying "You can use this any way you find useful - perhaps
even coming up with tricks we haven't considered  - but please keep in
mind these known situations that could cause difficulty".

> mentioning all possible disasters one can end up in - it 
> would read much nicer. Honestly, after reading for about 1-2 
> hours one day, I almost got headache and started to wonder 
> why am I trying to use subversion if it is full with traps 
> and possible disasters :)