Nathan Kidd wrote:
Bruce Wilson wrote:
* Interleaved the releases by date with the vendor branch. My
repository now contains rev 362 (2008) followed by rev 363 (1995)
which could be confusing. The effort may have outweighed the
benefit, so this was a low priority.
Of course this only works if it's okay for the existing repo's numbers
to change. (I.e. any logs, records, etc. that reference revision
numbers will suddenly be wrong if you interleave the changes).
This wasn't the case in my migration (no revs named in comments), but I
can see how that would be important to consider. Best approach I can
think of to achieve this would have been to split the migration dump
file every time I wanted to inject a Vendor commit (about 150 in all).
Too much work.
* Edited the dumpfile to make the developer names consistent. (We
used first name, then employee number, then
first-initial-last-name at various times.) Changing the "length"
entry right before each developer name would have been trivial in
the same search-and-replace.
With only 2,900 revisions, an after-migration 'svn propset' would
actually be easier, IMO. Remember author names are revision
properties, and not versioned, so your history won't be full of 2,900
"author changed" revisions.
Hmm, that sounds interesting. The tricky thing would seem to be
identifying which revs need to be updated, right? I could grep (a copy
of...) the revprops folder for clues I suppose. Know of any scripts or
recipes for this?
* Not spent so much time experimenting with rev-interval
settings. It didn't make enough difference to be worth the effort.
* Migrated about two years ago. We've already reaped significant
benefits from the move. But also...
* Since I waited this long, it might have been worth waiting a
little longer for Subversion 1.5 to take advantage of sharding.
When (if? :) 1.5 comes out you can easily shard by a dump-load cycle,
so there's no real benefit from waiting.
True, and I've seen an in-place reshard script is around, too. If 1.5
isn't far off, I can save myself the reshard as well. My main job is
billable work for clients, so anything involving "reloading the
repository" (which is already apparently working) doesn't win many points.
_______________________________________________
vss2svn-users mailing list
Project homepage:
http://www.pumacode.org/projects/vss2svn/
Subscribe/Unsubscribe/Admin:
http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org
Mailing list web interface (with searchable archives):
http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
