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

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