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

RE: Question: Rev 914 (ACK!)

From: Jay Freeman \(saurik\) <saurik_at_saurik.com>
Date: 2002-01-17 21:07:35 CET

Greg:

What really got me in this case was, starting from a tagged version you
can't just diff against the next revision. Let's say that Bob is the
main developer. He wrote foo.c, then tagged the distribution, and then
made 2 changes to the file in the main trunk. I check out the tag. The
revision my tagged files comes from is 5. The revision the file was
originally in was 4. The file got updated in 7 and 9. My file is
entirely incompatible with those other two because it is in a different
location in the grand file system. If I ask for a diff of
/tags/0.8.0/foo.c, that file only exists in 5, and didn't change between
5 to 7, and didn't change between 7 to 9. The original file,
/trunk/foo.c, did change. In CVS, the tag I have would BE /trunk/foo.c
"sticky tagged" to a specific revision. When I ask for diffs, updates,
etc. there is no question what file I want that diff from. What I need
to do is take my file, and figure out what it is a copy of (as I can't
just assume it is a copy of /trunk/foo.c as it might be a tag of a funny
named branch or something), by walking back the copy path to
/trunk/foo.c:4. Then I can use svn log or something to figure out that
the next version is /trunk/foo.c:7 and perform my diff.

The "problem" is that I have 2 steps, one of which is non-obvious. A
client can't be made to automate this, because if I'm working with a
"branch" rather than a "tag" then the file _hasn't_ changed. I might
_choose_ to try a newer version from a different branch, but the
interface wouldn't know which case it is dealing with unless there is a
standard notion of what a branch is versus a tag.

What happens when I want to do the equivalent of a CVS update, and have
a mixed revision directory here? I've read some of the documents where
mixed revision directories were discussed, but there was always a tacit
assumption that the end user was still working with different revisions
of the file from the _same directory_. Here I want /trunk/foo.c:7
checked out into /tags/0.8.0:5, and I need Subversion to understand that
if I roll back to /trunk/foo.c:4 there should be no difference reported
between this working copy and one that has /tags/0.8.0/foo.c:5.

Well, I'm really beat and not even thinking clearly at this point, so I
think I should call this e-mail "done" and get something to eat :).

Sincerely,
Jay Freeman (saurik)
saurik@saurik.com

-----Original Message-----
From: Greg Stein [mailto:gstein@lyra.org]
Sent: Thursday, January 17, 2002 11:21 AM
To: Ben Collins-Sussman
Cc: Jay Freeman (saurik); svn-dev
Subject: Re: Question: Rev 914 (ACK!)

On Thu, Jan 17, 2002 at 10:29:31AM -0600, Ben Collins-Sussman wrote:
>...
> I'm not sure I see the problem, Jay.
>
> Once we 'unbreak' our log command, you can run
>
> $ svn log foo.c
>
> And see a list of revisions in which that particular node changed,
> even if the node lives within a tag. You can then do 'svn diff'
> commands between (relevant) arbitrary revisions of the file, much like
> the way 'cvs rdiff' works.

The "problem" is that you have two steps. In CVS, you can diff against
N.M-1
to see a file's change. In Subversion, you must do an "svn log" first,
to
discover the prior change rev.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.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:57 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.