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

Re: svn merges vs. 'cvs2svn --cvs-revnums' properties

From: Peter Wemm <peter_at_wemm.org>
Date: Thu, 5 Jun 2008 22:25:44 -0700

On Thu, Jun 5, 2008 at 10:05 PM, Garance A Drosihn <drosih_at_rpi.edu> wrote:
> At 11:51 PM -0500 6/5/08, Ryan Schmidt wrote:
>> On Jun 5, 2008, at 23:44, Garance A Drosihn wrote:
>>> The following issue just came up on a large CVS repository which was
>>> converted to svn. We're also trying out version 1.5.0, because we
>>> really like the new merge capabilities.
>>> The --cvs-revnums option will:
>>> Record CVS revision numbers as file properties in the Subversion
>>> repository. (Note that unless it is removed explicitly, the
>>> last CVS revision number will remain associated with the file
>>> even after the file is changed within Subversion.)
>>> Thus, if you have a project with multiple branches, then the same
>>> filename may have different values for cvs2svn:cvs-rev in different
>>> branches. If we then go to merge changes in from one branch to a
>>> different branch, we get into a bunch of merge-conflicts.
>> If you're asking how to batch-remove file properties from historical
>> revisions, you may be interested in svndumptool.
>> http://svn.borg.ch/svndumptool/
>> It has a "transform-prop" function which can transform file properties.
>> Not sure if it has a built-in ability to delete file properties, but if not,
>> that could probably be added without too much trouble.
> Heh. I'm not really sure what I'm asking for... :-)
> I think we have a reasonable plan for our own repository, so I'm not
> looking for some emergency fix from anyone here. It's more that I
> just wanted to point out the issue. It's certainly one which did not
> occur to us until we actually started merging updates from one branch
> to another.
> I also don't have a lot of experience with the new merging feature yet,
> so I just have this vague feeling that the same issue might come up
> with some other uses of file-level properties. I can't come up with a
> good example though, so all I have is the vague feeling.
> Thanks for the pointer. svndumptool looks useful.

The main problem with svndumptool is that it is kinda sluggish on
giant dump files.

This **HACK** is more along the lines of what I was thinking of for
our repository and is quite a bit speedier:

Index: svndumpfilter/main.c
--- svndumpfilter/main.c (revision 31609)
+++ svndumpfilter/main.c (working copy)
@@ -758,6 +758,9 @@ set_node_property(void *node_baton,
       value = filtered_mergeinfo;

+ if (strcmp(name, "cvs2svn:cvs-rev") == 0)
+ return SVN_NO_ERROR;
   write_prop_to_stringbuf(&(nb->props), name, value);

   return SVN_NO_ERROR;

Yes, it is an evil hack..

Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5
"If Java had true garbage collection, most programs would delete
themselves upon execution." -- Robert Sewell
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-06 07:26:21 CEST

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

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