Kevin Puetz - Re: svn diff branch woprking copy against mainline? (original) (raw)

This is the mail archive of the gcc@gcc.gnu.orgmailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

I'm replying to a thread off of gcc-devel, but as I think I may have just had a thought that hasn't already been chewed through. So, I'm shifting to subversion-devel. If I'm wrong and this is already debunked, just shoot me down...

Branko Äibej wrote:

Andreas Schwab wrote:

Branko Äibej brane@xbc.nu writes:

Paolo Bonzini wrote:

More formally, you can say that any file in the checkout is made of BASE/DIR/filename where BASE is the URL passed to the latest `svn co' or svn switch' command.

The current SVN working copy philosophy (the same as CVS's, by the way) is that every working copy directory is self-contained. If we start recording command parameters in the working copy, we break that property.

Isn't this what the "Repository Root" from svn info gives?

No, that's the root of the repository, not the parameter given to "svn co".

If you

svn co svn+ssh://gcc.gnu.org/svn/gcc/trunk

the repository root that gets recorded is

svn+ssh://gcc.gnu.org/svn/gcc

The same root is recorded if you

svn co svn+ssh://gcc.gnu.org/svn/gcc/branches/bounded-pointers-branch

-- Brane

Sure. But svn info also knows (and has known for far longer) the URL. and URL with the Repository-Root prefix whacked off is BASE/DIR. So that info is obtainable.

Actually, I just had a thought I haven't seen proposed before (and I have followed several of these discussions). This wouldn't have worked before 1.3, since we didn't know the repository root, but it ought to Perhaps (stealing a page from patch) a good, and familiar 'swizzle' syntax would be -pN:/path where N is the number of initial directories to prune between the repository root and the current URL, and /path is the prefix to tack on instead.

so, for the most common cases, we'd have which would do

svn info

URL: svn://root/trunk/subdir Repository-Root: svn://root

svn diff -p1:/branches/foo bar.c baz.c (trunk to branch)

which would mean: # svn diff --old svn://root/trunk/subdir --new svn://root/branches/foo/subdir bar.c baz.c

svn info

URL: svn://root/branches/foo/subdir Repository-Root: svn://root

#svn diff -p2:/trunk bar.c baz.c (branch to trunk) which would mean: #svn diff --old svn://root/branches/foo/subdir --new svn://root/trunk/subdir bar.c baz.c

This feels like it translates pretty straightforwardly onto the existing --old and --new primitives, doesn't break the SVN "it's a filesystem" paradigm, and it's pretty agreably terse for common operations and repository layouts.

It probably needs some way to reverse the interpretation of old and new, since reversing the order and doing -p/path:2 looks weird and has a quoting problem to find the :. Maybe +pN:/path? Or just svn diff --reverse.

It's mildly annoying to have to think about the depth of the current WC, but I don't really think it's too bad - it wouldn't work well for scripting, but --old and --new work find for that - scripts don't mind the typing.

Ok, here goes nuthin'...

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]