[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnsquash has grown new capabilities

From: Blair Zajac <blair_at_orcaware.com>
Date: Wed, 07 Oct 2009 13:12:16 -0700

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


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.


Received on 2009-10-07 22:13:04 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.