Sparse updates

2010-11-09 Thread Klaus Ganser
Hello,

I have a simple feature request for the svn update command, so I'd
like some feedback on the utility of this feature.  In the past, I've
wanted to perform a sparse checkout of several different parts of a
repository, so I've started by checking out the root using
--depth=empty:

svn co --depth=empty svn+ssh://svn.example.com/trunk/ trunk/

>From here, if I wanted to download the contents of /trunk/a/b/ and
/trunk/c/d/e/ without any extraneous files or directories, I would
have to first check out all of the intermediate directories in the two
paths explicitly:

svn up --depth=empty trunk/a/ trunk/c/
svn up --depth=empty trunk/c/d/
svn up trunk/a/b/ trunk/c/d/e/

What I'm proposing is that svn update have a --parent flag that would
perform these intermediate updates as necessary for the requested
update paths, much like mkdir.

Thanks,
Klaus


History of a fixed path across all objects

2010-11-10 Thread Klaus Ganser
Hello,

I originally asked this question on stackoverflow:

http://stackoverflow.com/questions/4140377/svn-log-of-a-fixed-path-across-copies-and-moves

Nobody seems to have a good solution to getting the history of a
specific path across all objects that ever lived in that path.  I've
been trying to stitch together the results of multiple queries using
`svn log --stop-on-copy`, but this is like throwing darts in the dark;
a particular path may not exist for certain revision spans, and I need
to hop over these when I issue an `svn log` request with a peg
revision.  This would be slightly more reasonable if when I requested
a peg revision in which the path did not exist I received an error
message telling me something like this:

svn: File not found: revision 1234, path '/branches/qa'
svn: Path does not exist between 1233 and 1235

instead of what I get currently:

svn: File not found: revision 1234, path '/branches/qa'

Ideally, however, there should be a way for me to tell svn that I want
the history of the *path* and not the object at that path at a
particular revision.  I'm mailing this list now for some advice.

Thanks,
Klaus


Re: History of a fixed path across all objects

2010-11-10 Thread Klaus Ganser
On Wed, Nov 10, 2010 at 11:32 AM, David Weintraub  wrote:

> You want the entire history of a file called "bar.java" in the path
> /foo/bar/barfoo from revision #1 to the current revision -- even
> though it isn't the same bar.java at that location?
>
> Is this correct?

Yes, that is correct.


Re: History of a fixed path across all objects

2010-11-10 Thread Klaus Ganser
On Wed, Nov 10, 2010 at 11:48 AM, Les Mikesell  wrote:
> If something is deleted and recreated there is no history connecting them
> even if those things have the same name, so what you are asking for doesn't
> really exist.  Maybe you could 'svn log -v' a parent or the top level of the
> repo and parse out the deletes/adds you want to see.

Running `svn log` on the top level of the repository is one of the
solutions proposed to my stackoverflow question.  However, this is
extremely inefficient for large repositories with long histories.  You
can imagine implementing a visualization tool that lets you zero-in on
a specific path and see what has lived there at any point between
revision 1 and HEAD.  It would be absurd if the command to generate a
view of this one path took as long as the command to view the history
of the entire repository.  I'm saying that this is a valid use-case
that the svn cli does not currently satisfy, but one which it could
easily satisfy because it stores all the necessary information.  As a
client, this should be as easy for me as something like this:

`svn log -v --path ...`

where the --path option would tell svn to stick to that path, not to
the pegged revision currently at that path.

-Klaus


Re: History of a fixed path across all objects

2010-11-10 Thread Klaus Ganser
On Wed, Nov 10, 2010 at 12:09 PM, Ryan Schmidt
 wrote:

> Are you sure? I think what the others are trying to tell you is that the 
> repository does not store this information, so there is not a way that any 
> client could return this information to you without doing an exhaustive 
> search.

I know that it has enough information to do this because I have enough
information to do the same thing with what the svn client currently
gives me - in a very inefficient way - by simply polling a specific
path at all revisions between 1 and HEAD.  I would hope that
internally svn would be implemented in such a way to efficiently
traverse any gaps in the path's existence, but even barring that, that
fact that a single command like `svn log -v --path ...` would
eliminate the network/IO overhead in accomplishing this task makes it
worthwhile.  I believe that this is a use case that should be
satisfied by svn natively, and not something that would require me to
build an extension to it with its own history.


Re: History of a fixed path across all objects

2010-11-10 Thread Klaus Ganser
On Wed, Nov 10, 2010 at 12:19 PM, Feldhacker, Chris
 wrote:

> I think you want the "--ignore-ancestry" option:

svn log does not support that option.


Re: Sparse updates

2010-11-10 Thread Klaus Ganser
On Wed, Nov 10, 2010 at 8:41 AM, Daniel Shahaf  wrote:

> Sounds useful to me.

I've submitted the feature request:

http://subversion.tigris.org/issues/show_bug.cgi?id=3748

Thanks,
Klaus


Re: Sparse checkouts automation

2010-11-11 Thread Klaus Ganser
On Wed, Nov 10, 2010 at 3:10 PM, San Martino  wrote:

> Is there a way with one command to sparse-checkout al the elements
> of the path to file1.txt (included) but no more than those elements ?

See the following thread:

http://mail-archives.apache.org/mod_mbox/subversion-users/201011.mbox/%3caanlktik0ompp2bvr64bnyqybyj-ct1r5wgxz1kpe3...@mail.gmail.com%3e

And here's the recent feature request:

http://subversion.tigris.org/issues/show_bug.cgi?id=3748

-Klaus


Re: History of a fixed path across all objects

2010-11-11 Thread Klaus Ganser
On Thu, Nov 11, 2010 at 5:17 AM, Johan Corveleyn  wrote:

> So, as far as I'm concerned, I think you can file this as a new
> feature request in the issue tracker (maybe first search for any
> similar outstanding requests).

Filed the bug here:

http://subversion.tigris.org/issues/show_bug.cgi?id=3749

It was promptly marked as a duplicate of this bug from 8 years ago:

http://subversion.tigris.org/issues/show_bug.cgi?id=928

It would be nice for this feature to see the light of day.

-Klaus