On Sat, Jul 20, 2013 at 2:16 AM, Andreas Krey <a.krey_at_gmx.de> wrote:
> On Thu, 18 Jul 2013 07:45:52 +0000, Nico Kadel-Garcia wrote:
> ...
>> * When ready to migrate from the old source control, do a clean dump of the
>> old system, and svn import into the new system into a branch, and make a
>> locked *tag*. Do not *bother* with the old history.
>
> I strongly disagree with that in that generality. While old history may
> be useless to have (and you have it in CC anyway), doing the switch on
> a single state is unnecessarily harsh. Instead treat a succession of
> states of the 'central' CC branch as a 'vendor branch' and import is
> as such into svn. This allows you to continue to run out feature team
> branches in CC until all of them have finished while being able to start
> new teams on svn beforehand.
My experience is from specificity, not generality. The engineering
time burned, and the bitter complaints about history discrepancies
from fundamentally distinct history reporting can easily triple the
cost and effort of the migration.
It's also an excellent opportunity to *trim* the project. Bring over
only relevant projects or source directories. Leave a "PROJECT.txt" in
place to point people to the old repository for discontinued projects,
but get them *out* of the source tree.
> While you may not care about *old* history, the history during the
> migration is highly helpful. Unless you can afford to do a single shot.
Leave the old history on the old source control system.
>> * Under no circumstances maintain parallel work for the same project in
>> Subversion and in the old Clearcase, and expect the Subversion history to
>> be reconcilable with the parallel Clearcase history
>
> While not trivial this is entirely possible as long as you only want
> to sew the two systems together at a single branch (not transferring
> the full history, just syncing).
And it's possible to extract your own teeth, and theoretically
possible to extract your own gall bladder. The clients will demand
that it be resynced, and resynced, and won't understand why you can't
just backfill the logs and changes from one system to the other, and
you life will be filled with pain. After all, they've got a few lines
of perl that work great for them, why can't you just use them?
>> except by throwing out
>> the Subversion repo and starting over from an import.
>
> 'Restart from scratch' seems to be a standard svn advice. :-(
> (Usually meaning 'do a new checkout'.)
No, not a new checkout. that just gets you a local working copy. I
mean "Build a new repository".
>> If I meet one more
>> oh-so-clever person who thinks reconciling such things is just a matter of
>> a few lines of perl, I will throttle them with their own intestines.
>
> Feel free to come over. I've been doing this for years between CVS and
> git with twentyfour lines of shell script and proper procedure (which
> is the hard part).
And this is just what I'd worry about. I wrote that bit above before I
saw this!!!! This is partially how I get paid. negotiating between
developer's one-off hacks to something that's safe and stable for
production use. It can be fun, but it can also be very, very expensive
in manpower and beer while the details get worked out.
So you have few lines of perl that work generally,b ut for CVS, not
Subversion, and expect it to work for Subversion? Admittedly, git is a
relatively easy environment for such attempts git has a similar model
of "master/tags/branches", that is conceptually similar to
Subverrsion's "trunk/tags/branches. So a lot of common cases are
feasible. But man, the edge cases are *very expensive* to try to
handle.
For example, try deleting an accidentally committed DVD image in git,
or an accidentally stored password record, and migrating that change
and the history back to Subversion. In fact, try backporting this from
a working git repository into the Subversion hsitory:
https://help.github.com/articles/remove-sensitive-data
Been there, done that, can't be done on a live Subversion repo for a
lot of reasons. (We could discuss why sometime, if you're interested.)
Received on 2013-07-20 17:50:39 CEST