[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merging and switching

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2002-01-24 02:27:12 CET

On Wed, 2002-01-23 at 18:37, Ben Collins-Sussman wrote:
> Given how rarely merges occur, is it worth jumping through hoops
> to reconstruct the fulltexts? Maybe it's just simpler to have
> the client grab the fulltexts directly. What do people think?

Implement it both ways and see if the faster way took too much effort.
:) Seriously, I think this should be left up to the person doing the
work. If that person does it the slow way and someone thinks it should
be faster, then get that person to redo it the fast way.

> and apply the context diffs right to our wc! In other words,
> Philip's fancy new diff-editor is already doing what we want.
> Cmpilato points out, however, that a *true* merge should be able
> to generate context diffs between any 2 arbitrary urls, which
> Philip's system can't yet do. Kfogel counters with the notion
> that for 99% of all merges, the two urls are identical anyway.

As far as I can tell, you guys are forgetting a golden rule of
usability:

                People like to use names, not numbers.

Because you're forgetting this rule, you're copying command syntaxes
from CVS without accounting for the fact that in CVS, you can use branch
and tag names for version numbers, whereas in Subversion you have to use
paths.

So, not only does merge need to handle two different URLs, so does
diff. I pointed this out in
http://subversion.tigris.org/servlets/ReadMsg?msgId=41945&listName=dev
but, even though Karl answered in the positive and appeared to
understand, I think my argument got lost in the noise.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:58 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.