Eric S. Raymond wrote:
> Mark Phippard <markphip_at_gmail.com>:
>>> Being in contrib/ doesn't mean "casual hack". It just means "maintained
>>> by a contributor", i.e., the Subversion project is distributing it along
>>> with Subversion but not taking any responsibility for it. So IMHO
>>> leaving it in contrib is the best course. Giving it unit tests is fine.
>> If there are several files, then it is probably worthy of a
>> sub-directory in contrib as we have done for other tools. Something
>> like contrib/server-side/svncutter
>>
>> Then a README and the tests etc. can all go into that folder.
>
> Noted. I'll resubmit when I have things polished to my satisfaction.
>
> Revision ranges for the -r option can now be comma-separated lists of
> ranges, with the obvious interpretation.
>
> I've added the abiliity to rename a property over the specified
> revision set. This is useful because svn commit helpfully won't
> twiddle svn:author and svn:date - at one point in my disaster
> recovery I was applying git diffs to a repo and had to stash these
> properties in git:auther and git:date, renaming them later with a
> silly little filter script. The proprename subcommand replaces that
> silly little filter script.
>
> I just got the 'excise' option for unconditionally removing specified
> commits during a squash working - I wanted this to be able to remove
> certain cvs2svn conversion artifacts.
>
> Another previously implemented subcommand I forgot to mention is "log"
> - run it and get the same output as if you had done svn log run on a
> repo created from the dump. I used "svncutter log" followed by an Emacs
> session followed by "svncutter setlog" to fix up all the annoying typos
> in my comment history.
>
> The current subcommand set (squash, select, propdel, propset, proprename,
> log, setlog) is all I had planned for the tool. I'll take requests, however,
> if any of you can think of a frequently requested dumpfile-surgery operarion
> that I've missed.
The one I've needed is when you're pulling a project out of a larger repository
into a new smaller one, so you want to the project up one or more directory levels.
For example, project foobar has a directory foobar in the repository
foobar/
trunk/
tags/
branches/
and you want a new foobar repos with just trunk, tags and branches at the top
level. So svndumpfilter works for pulling foobar, but not for moving it up.
Regards,
Blair
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2404663
Received on 2009-10-07 22:13:04 CEST