Re: lsvtree?

Daniel Patterson wrote:

> K. Richard Pixley wrote:
>> I know that subversion isn't intended to compete with clearcase, but in
>> clearcase, the "lsvtree" command will provide a textual, (xlsvtree
>> provides a graphical), representation of the branching ancestry of an
>> element, (ie, a file or directory). Since clearcase branches exist in a
>> domain orthoganol to file name but similarly heirarchical to each other,
>> this is easy to convey with a simple format akin to "ls -R" or, in the
>> case of graphical display, using a simple visual tree representation.
>>
>> What is the svn command for producing this information?
>>
>> That is, how do I locate all copies of a particular file or directory
>> from the command line? And what is the command line for determining
>> their relationship to each other?
>
> The answer is, right now, there is no easy way to do that. In fact,
> it's somewhat more complicated because of the way Subversion
> implements "branches" (as cheap copies). To branch (and to use
> Clearcase terminology here) an element, you can copy either the
> element itself, or any one of it's parent directories. If you copy
> it's parent (i.e. copy /trunk to /branches/foo when you're interested
> in /trunk/a/b/c.txt), then it's a quite expensive operation to
> work out that in fact, a/b/c.txt was copied too. There is no
> easy way to work that out, except for traversing the revision
> history of the repository and looking out for interesting
> operations (like copies of /trunk, /trunk/a and /trunk/a/b).
>
> As Ramaswamy pointed out in another mail, there is a script
> in tools/client-side/svn-graph.pl which gets close but doesn't
> quite do that. It'll trace an element for "direct copies",
> but not for "implied copies" where a parent is copied. I think
> it'll notice if an element is modified on a branch after it is
> copied, but I haven't tested that (I wrote the script basically
> to follow the history of /trunk).
>
> The clearcase branch tree (as pointed out in another recent
> email) is orthogonal to the filesystem tree, and applies to each
> "element". In Subversion, the filesystem tree *is* the branch
> tree, and it's somewhat difficult to map between the two. A
> fellow employee and I have had several long talks about how one might
> map between the two, but so far, we haven't come up with a clean
> algorithm.
>
> In fact, one of the problems is that Clearcase's history is not
> immutable. Labels and branches can be moved, with no history
> kept of that change, which makes it real hard to map to Subversion
> sometimes (and we've banned moving labels in our Clearcase
> installation for exactly that reason).
>
> I've been pondering for a while how an "svn_get_decendents()" function
> might be added to make it easier to follow the history of a file
> forward. Right now, you can only really trace backwards (unless
> you do lots of work processing).
>
> daniel

Here's another approach (probably even chintzier than svn-graph.pl, which I
didn't know about). But I'll throw it out, because it works well for me :-)

I use a little bit of XSLT that I use to take a log -v --xml of the tags
dir, and map which tags that were created from a given source revision, and
what the source path was (basically it just turns the node-copyfrom data
inside out). Then, a second XSLT produces an HTML changelog from that tag
data and a log --xml of the WC, which gets dumped in with the online help
by the nightly build script.

I have to scan the changelog myself if I want to to work out where a given
file went, but it seems to be good enough for the way we work; tags of
mixed-revision copies are mighty confusing anyway you look at it. There's
some cruft that shows in my logs due to cvs2svn and converted vendor
branches (so that tags have some stuff from trunk and some from vendor
branches, even though that trunk revision would have been an
identicalsource ). I keep thinking about trying to resolve those, but other
than that it works for us...

Feel free to use if it's helpful to you. I think this is the current
version; if not, I'll reply to myself Monday.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org