Blair Zajac wrote:
> Mark Phippard wrote:
>> On Fri, Feb 29, 2008 at 1:17 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>>> C. Michael Pilato wrote:
>>> > NOTE: Everyone will need new working copies after the cutover --
>>> > history has been munged. Also, folks who've been using svnsync to
>>> > mirror the repositories will need to start anew with fresh mirrors.
>>> What do you mean by "history has been munged"?
>> He is making changes to properties as part of the merge process
>> (changing history). We do not have a mechanism for conveying this to
>> the working copy (one of the problems svn obliterate would also have
>> to solve).
>> Specifically, as revisions are synched he is:
>> 1) Ignoring/stripping any svn:mergeinfo properties
>> 2) Converting any svnmerge properties to svn:mergeinfo properties.
> I see, that type of history munging.
> Doing the cutover to the new collab.net 1.5 repository should be done
> with an 'svnadmin upgrade' though, right? Not with a custom svnsync
> copied repository, since nobody else will be doing that style of
> upgrade. This is just a measure for testing.
As far as I'm concerned, this community can make that decision.
I had hoped to actually use the svnsync repository so we could all benefit
from the pretense that we'd been using merge tracking all along. (And also,
not knowing if in our history there are invalid proto-forms of the
svn:mergeinfo property that might cause segfaults or worse when we hit 'em.)
Several other folks have expressed interest in the same.
But if folks want to do a tip-of-the-tree only migration of svnmerge
properties to svn:mergeinfo (using the svnmerge-migrate-history.py script)
and just suffer from whatever badness might exist due to their possibly
being older, incompatible forms of the svn:mergeinfo property in our
repository history (due to us using unrelease code against our own
repository), so be it.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-02-29 19:35:33 CET