Guten Tag Holger,
On Mon, Mar 02, 2009 at 11:29:53PM +0100, Holger Stratmann wrote:
> >We have a legacy repository which will continue to be used while we
> >migrate all of our products to a new, refactored repository.
> Define "continue to be used"?
> People will still commit changes to the legacy repo, right? (judging
> from your text)
> Why?
> Big question: Will they also commit changes in the new repo?
There will be ongoing development (commits) in both repositories.
We are doing this because one of our products will do another release
from the legacy repository. At the same time, several other products are
migrating to a brand new structure and a brand new build system.
I recognize that this is a recipe for disaster, so changes to some
products will be made only in the legacy repo while changes to other
products will be made only in the refactored repo. This will be
enforced via education/policy or (when that doesn't work) by pre-commit
hooks.
> >The legacy
> >repo will live on for at least 6 months while new development proceeds
> >in the refactored repo.
> Also: Why?
> Are you planning to migrate the history as well? Or do you make a "cut"
> and lose all the history? (I'd call that a "gotcha", but YMMV, of course)
The product that will live on in the legacy tree is big and complex and
has an old, crufty build system. One of the reasons for going to the
refactored repo is to break that product up into smaller pieces and to
replace the crufy build system with something modern.
I definitely prefer retaining all the history, but it might be
acceptable to have a cut -- e.g. All revisions before
$ARBITRARY_TIMESTAMP are in this repository; if you need something
older, look in the old repository.
> >Currently, we have a script that checks out the latest from the legacy
> >repo, massages the checkout into the refactored form, and imports the
> >massaged checkout into the refactored repo. This process must be
> >performed manually and is tedious and error-prone (files that were added
> >or deleted since the last migration need to be handled specially with
> >svn add and svn rm in the refactored repo).
> >
> >What would be better is an automated process to handle all this.
> Definitely.
> Question: How often (how many times and in which intervals) are you
> planning to do the "synchronization"?
What would be best is to have it happen continuously. The way I see it,
every commit in the legacy repo triggers a post-commit hook that dumps
the committed revision, massages it, and sends it to the refactored repo
for import. Conflicts or other abnormal conditions would require manual
intervention.
Something less frequent might be acceptable (particularly if the
resolution is "every hour" or "every 15 minutes" or something).
> Can you tell us in one (or two) sentences
> 1) why you're switching to a new repo? (instead of refactoring the old one)
We will be releasing new versions of products from each repo for the
next year or so, so we need to be able to have both "views" on the
source code simultaneously.
It might be possible to handle this with branches (as you suggest below)
but I feel like that would turn into a tangled mess very quickly. Would
merges from the "legacy branch" to the "refactored branch" work
correctly if one of those branches has a bunch of files moved to
different paths? Would a developer be able to follow and understand the
history after a few of these merges?
> P.S.: Of course you would make a tag or a branch before you start the
> refactoring: If people still need access to the old structure, they can
> have it. They can even commit changes to the old structure and merge
> them to the new structure "in a somewhat deterministic fashion"... (I'm
> not sure how well Subversion handles this type of merge (to files which
> have moved) and if it would be considered a "tree conflict"? In any
> case: Merge tracking could help you keep track of merges...)
If anyone has experience with this, I'd love to hear it. I'll set up a
test repo and play with it when I have time but if someone knows
something already that would be helpful.
> 2) why you want to keep them in sync for a while instead of switching
> "Sunday, 12:00:00 PST" (or whichever timezone you choose ;-)).
Products will be released from both repositories simultaneously.
> Personally, I think it would be better to have a "big bang" change for
> each project (not necessarily the whole repo) AND use "svn move" to do
> the refactoring.
> You'd keep your entire history, which would be a big plus.
The projects are, of course, tightly-coupled (In fact, I have been known
to refer to their relationship as 'incestuous' :)) so that moving each
project independently is not easy.
> Also, if the files reference each other in any way (which they usually
> do!), either the old or the new repo would be "broken" during the six
> months... if you're planning to adjust all references during the
> "massaging" part, you're up for quite a bit of work which doesn't sound
> trivial...
The fact that there are two complete build systems involved mitigates a
lot of this ugliness. The legacy build system knows how to find things
in the legacy repo; the refactored build system knows how to find things
in the refactored repo.
Thanks for your questions and advice, Holger. Hopefully this makes
things a little clearer and y'all can give me more suggestions!
Thanks,
tyler
Received on 2009-03-03 00:12:01 CET