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
"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
svn cp http://svn.ninetjer.org/svn/optasia/tags/optasia-gdc_2001
(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
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).
Jay Freeman (saurik)
----- Original Message -----
From: "Garrett Rooney" <email@example.com>
To: "Ben Collins-Sussman" <firstname.lastname@example.org>
Cc: "SVN Dev List" <email@example.com>
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 rooney Unix was not designed to stop you from
> firstname.lastname@example.org doing stupid things, because that would
> http://electricjellyfish.net/ stop you from doing clever things.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Oct 21 14:36:59 2006