RE: the truth about merge tracking

> -----Original Message-----
> From: pobox_at_verysmall.org [mailto:pobox_at_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 :)

From my experience, most people who are not steeped in Opensource or
Linux culture prefer to be told "the one true way" to use products.
This is why Microsoft is so successful with their marketing. Perhaps
the book should be broken into two sections: one for the "this is how
you do it" and "for you tech geeks out there, this is how you REALLY do
it".

David

--
All developers are lazy as evidenced by the amount of time and effort
spent in making a computer do the work. 
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org