[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem mergin moves from different repos

From: Walden Mathews <walden_at_eqwality.com>
Date: 2004-10-19 22:51:03 CEST

FWIW, I've just successfully led a conversion from
Merant Dimensions to Subversion. Well, in truth we
are not fully migrated, but the migration process is
by now well known, documented and used.

Going back a couple of months, I began mirroring
the Dimensions base in a Subversion branch. This
looks a lot like what you guys documented as "vendor
branching", with a twist.

I import each day's drop from the other system,
merge from the head of the target branch to the drop
branch, and lay those over the target branch working

All added files show up, of course, as adds with
history, but this is not desirable. I then run an ant/xslt
target to fiddle with the svn metadata, removing all
the "copyfrom" shtuff. Svn status now shows just a
bunch of local adds, and I commit that.

There may be other (better) ways of doing the
"forgetting" step above, including perhaps using
an xcopy to port the svn metadata over to a clean
(non subversion) drop copy. Dunno....didn't try.

Anyway, I wonder how other people deal with the
problem of bringing a second repository system along
side an existing one, or if I'm the only one insane
enough to try such a thing. It really helped sell
management and team on the merits of Subversion to
take this approach. I would do it again.

And the purpose of writing all this is to underscore
the utility of a cross-repository merge capability with
relaxed history rules. Yes, A Good Thing.

Walden Mathews
(203) 952-6986

----- Original Message -----
From: "Archie Cobbs" <archie@dellroad.org>
To: <kfogel@collab.net>
Cc: "Archie Cobbs" <archie@dellroad.org>; "Guille -bisho-"
<bisho@eurielec.etsit.upm.es>; <sussman@collab.net>;
Sent: Tuesday, October 19, 2004 4:21 PM
Subject: Re: Problem mergin moves from different repos

| kfogel@collab.net wrote:
| > > > Erk -- I see a lot of complexities here, as you can tell, but I'm
| > > > gonna have to drop out of the conversation, Archie, sorry. Just
| > > > pressures, nothing else.
| > >
| > > No problem.. I'd like to file an enhancement request though (and point
| > > it at this thread).. is that OK?
| >
| > Well, hmmm. I'd prefer not to, only because I don't really think
| > there *is* a workable plan there (which must be frustrating, since I'm
| > not spending the time to really say why). I'd feel better if you
| > could find some developer who would say "Yeah, I'd implement that if I
| > had the time" or "Yeah, I agree that's a good partial solution".
| Oh nevermind, I give up.
| I'm too busy to explain this idea again or jump through any more
| hoops.. if it hasn't registered with any developers by now then it's
| not of sufficient interest. I'm kindof surprised, but hey whatever..
| inter-repo merging seems like a feature lots of people could use.
| > Why not just toss the copy history entirely when doing a
| > different-repository merge?
| >
| > Oh, there I go getting into the subject again :-).
| That would be fine with me! I just want to be able to merge in patches
| from one repo to another (not an unreasonable feature request IMHO),
| even if that means history is not handled "optimally" for copies.
| -Archie
| __________________________________________________________________________
| Archie Cobbs * CTO, Awarix * http://www.awarix.com
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
| For additional commands, e-mail: dev-help@subversion.tigris.org
| __________ NOD32 1.897 (20041018) Information __________
| This message was checked by NOD32 antivirus system.
| http://www.nod32.com

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 19 22:51:12 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.