On Sat, 20 Jul 2013 11:50:06 +0000, Nico Kadel-Garcia wrote:
> On Sat, Jul 20, 2013 at 2:16 AM, Andreas Krey <a.krey_at_gmx.de> wrote:
...
> My experience is from specificity, not generality.
Me too. Only I'm just seeing a project where it takes months to
get all the support stuff working for the new VCS again, and
a single cut point doesn't even look feasible.
> 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.
I'm promising transferring the cumulative changes,
not the exact history.
> It's also an excellent opportunity to *trim* the project. Bring over
> only relevant projects or source directories.
Oh, coming from clearcase it can be quite the pain to just get it
to compile and run again. There can be myriads of places in the
sources and buildfiles where pathnames start absolutely with
/vobs/... where your svn checkout never will be.
It can also be pretty painful to find out what *is* relevant.
...
> > 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).
(I forgot to mention: 'syncing'. Not dealing with the same work
being done in CC and svn, slightly differently, and then expecting
that to merge well in any way. (But that is just like doing the
same work on two branches.)
> 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?
Just ask them to use their own few lines of perl to do that.
> 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.
My client knows that. :-) Besides, the transfer is not (quite)
a production job; it needs to live for a limited time span, and
can require a bit of handholding. Yes, it won't work in half
an hour (or day, possibly week), but it is worth it to smooth
the transition.
> 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",
Forget the tags. 'Single branch'. What can be mapped into a succession of
tar files. I only track a succession of states of the master/trunk/MAIN
branch of the source repo into a vendor branch (to use svn parlance). That
is enough to be able to gradually phase out the old VCS and not needing
to do it in a single (long) instant where nobody can work. With a century
of developers I can invest a lot of time to save them a day of complete
downtime.
As soon as you try to figure out multiple branches and the
merge info you get into many-moons-project very fast.
> 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.
My current source repo also has very few strange and no non-ascii
characters in the filenames. :-)
> 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
No way. I'm aiming for what helps the migration, not for what might
be implementable given infinite ressources.
Basically, I'm one step away from you in the spectrum of possibilities;
you take a single snapshot; I take a single sequence of them.
> 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.)
Beginning with 'svn obliterate' still not existing. But: Doing the
above (git filter-branching your repo) has similarly bad consequences
for your developers as dump-filtering an svn repo.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2013-07-20 18:47:01 CEST