On Sat, Jul 20, 2013 at 2:16 AM, Andreas Krey <a.k...@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.)