Hey Tyler,
> Do you see any gotachas in my overall strategy?
Well, it depends... just a few questions:
> 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?
> 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)
> 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"?
> I could write something that uses svnadmin dump on the legacy repo, then
> massages the dump files, then does svnadmin load on the refactored repo.
> svndumptool looks like it can handle the massaging
Question (again): Will people also commit to the new repo?
In that case, you might have a big problem here, because you will have
to merge (!) the changes. How would you handle that?
> - Am I completely off-base in my approach?
I'm not sure.
Can you tell us in one (or two) sentences
1) why you're switching to a new repo? (instead of refactoring the old one)
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 ;-)).
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.
In case your changes are very complex, you can do "test runs" by copying
the repository to a test machine.
I'd write a script (shell script or batch file) that does the entire
refactoring and test it thoroughly before using it on the "production
repository".
I'm guessing you'll also have to adjust some other scripts and utilities
(compile / build / deploy / test) for the new repository structure.
Since subversion repositories are so easily copied, I would develop and
test all that on a spare machine and then "flip the switch" when you're
done.
Remember: "Copies are cheap" (and so are moves): When everything is
properly scripted and working, the restructuring should only take a
couple of seconds!
In theory, people wouldn't even have to know about it and get the new
structure with the next update. In practice, I'd make sure nobody has
uncommitted local changes when you do this... just so much easier for
everybody ;-)
One poor person (you?) usually does that on a Friday evening and has to
sacrifice a weekend in case things go wrong ;-)
You could do one product per week if that is possible (no dependencies
between the products?).
> Is there a better/cleaner/easier way to keep these repositories in sync?
Keeping them in sync sounds like a lot of work and a source for errors
with no clear benefit (unless you can tell us one) - or even a
disadvantage...
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...
> I'm happy to provide more details
Go ahead :-)
Holger
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...)
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1258534
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-03-02 23:31:01 CET