Philip Martin <philip@codematters.co.uk> writes:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
> > (cmpilato, would you like to better explain that? My recollection is
> > that you concluded that svndumpfilter couldn't possibly work correctly
> > on copies, unless the functionality were merged into the core code of
> > 'svnadmin dump'.)
>
> I am aware of a problem with copies. If svndumpfilter filters out
> /some/path and the repository contains items copied from paths under
> /some/path then the copies get filtered out as well. That works
> perfectly until a subsequent revision attempts to modify the copy and
> finds that the copy does not exist.
That's basically the problem that Ben is talking about. I strongly
feel that the functionality that svndumpfilter wants to offer should
be provided by 'svnadmin dump' directly, and have even begun sketching
out some plans for exactly that. But the repos layer doesn't give me
the hooks I'd like to have, so this functionality now has to move even
deeper -- into libsvn_repos itself.
The downsides of this is that the *idea* behind today's svndumpfilter
is much more functionally elegant because it allows you to dump your
repository one time, and then do any number of transformations on that
dump. Moving the functionality into 'svnadmin' itself means that
folks have to actually perform all the custom dumps, something I
anticipate to be a much slower process. But then again, from a
technical standpoint, svndumpfilter is doing text parsing and
crunching, for crying out out -- this whole program *screams* to be
replaced with a Python script.
The copy problems could be solved if svndumpfilter was also passed a
/path/to/original/repos, so that anything it needed to grab to make a
filtered transformation complete, it could do. I hesitate to go that
route though ... feels yucky.
Anyway, it's very likely that I'll spend a few cycles just making
'svnadmin dump' more robust, and then scrap the dumpfilter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 13 01:36:44 2003