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

Re: Please help me figure out merging strategy after a 1.4 => 1.5+ transition

From: Tyler Roscoe <tyler_at_cryptio.net>
Date: Thu, 18 Jun 2009 09:12:03 -0700

On Wed, Jun 17, 2009 at 09:48:05PM -0400, Jamie Jackson wrote:
> We migrated from server version 1.4 to 1.5+ earlier in the year (3-4
> months ago). However, it wasn't until a couple days ago that we
> started filtering out <1.5 (auto-merge-unaware) clients with a commit
> hook. Therefore, we've had a mix of merge-aware and merge-unaware
> clients using the repos for a while now. I think that people stuck
> with old-school merging techniques during this time, but still, I
> guess the new clients would have been leaving behind some merge info.

I've never worked with merge-unaware clients but my strategy would be to
"insure" (by whatever means possible) that all merges that are supposed
to be performed have been performed. Then, you could either:

- just keep working from there, assuming that no one is going to go back
  in time to merge things that have already been merged.

- do a --record-only merge for all likely merge scenarios
  (--record-only merge from trunk into the active release branch, or
from the release branch into trunk, depending on your branching
strategy).

Remember to turn on your hook script that rejects <1.5 clients.

Communication to all your users about these steps is implied, of course.

While this scenario is annoying, I think it would be hard to really mess
anything up as long as your users recognize the kinds of conflicts that
can happen when you do a merge multiple times. I would also encourage
your users (or your merge monkey) to really inspect the diffs before
committing a merge to minimize the potential for heartache.

hth,
tyler
Received on 2009-06-18 18:12:57 CEST

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

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