[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: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-01-24 22:56:26 CET

Yep, yep -- "svn merge" needs to be able to take two distinct paths.
I stand [well, sit] corrected, thanks for the quick responses.

-K

"Jay Freeman \(saurik\)" <saurik@saurik.com> writes:
> Subversion's architecture shoots itself in the foot here. Because there is
> no difference between a "branch" and a "tag", I can rewrite your sentence
> like this:
>
> "well, as i said on IRC earlier, i can't come up with a use case that would
> involve diffing two different _tags_ and applying the results to a third."
>
> Well, I sure can :).
>
> I branch the main line of Optasia away from the code that Jake and Tony are
> working on so I can get ATI Radeon 8500 support in without destroying what
> they are doing. I branch from an existing tag. I figure to do this I'm
> doing:
>
> svn cp http://svn.ninetjer.org/svn/optasia/tags/optasia-gdc_2001
> http://svn.ninetjer.org/svn/optasia/branches/optasia-radeon_8500
>
> (please god all mighty don't tell me I need to check out either repository
> to do this...)
>
> OK, so now Jake is working on the next major milestone (the E3 game demo).
> Let's say he finishes that (dedicated worker he is), but I've been spending
> so much time fighting with our old CVS repository that I'm _still_ working
> on Radeon support. So, I want to do the following merge to get the new
> updates to my working copy:
>
> svn merge http://svn.ninetjer.org/svn/optasia/tags/optasia-gdc_2001
> http://svn.ninetjer.org/svn/optasia/tags/optasia-e3_2001
>
> I figure merging diffs between two tags will be the 99% case, diffing
> between arbitrary revisions sounds like something only a developer who is
> really pissed off is going to do (as in my description of that scenario a
> week or two ago).
>
> Sincerely,
> Jay Freeman (saurik)
> saurik@saurik.com
>
> ----- Original Message -----
> From: "Garrett Rooney" <rooneg@electricjellyfish.net>
> To: "Ben Collins-Sussman" <sussman@collab.net>
> Cc: "SVN Dev List" <dev@subversion.tigris.org>
> Sent: Wednesday, January 23, 2002 7:15 PM
> Subject: Re: merging and switching
>
>
> > On Wed, Jan 23, 2002 at 05:37:58PM -0600, Ben Collins-Sussman wrote:
> > > So, what method to use? And, do we need to stay flexible and
> > > accept 2 different urls?
> >
> > well, as i said on IRC earlier, i can't come up with a use case that
> > would involve diffing two different branches and applying the results
> > to a third. it seems like two of the three things involved would just
> > be different revs of the same branch, and you'd be applying the
> > difference between them to another branch. (apply the difference
> > between rev 6 and 7 of branch foo to the trunk, since we fixed a bug
> > in that commit that still exists in the truck...)
> >
> > even if we can come up with a use case for this, we should ask
> > ourselves 'how common is this', and 'how hard will it be to write'.
> > if it'll be difficult and not commonly used, then i don't see why we
> > shouldn't put it off until after 1.0.
> >
> ...
> >
> > looking forward to hearing everyone else's opinions on the matter,
> >
> > -garrett
> >
> > --
> > garrett rooney Unix was not designed to stop you from
> > rooneg@electricjellyfish.net doing stupid things, because that would
> > http://electricjellyfish.net/ stop you from doing clever things.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

---------------------------------------------------------------------
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:59 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.