On Tue, Jul 28, 2009 at 2:36 PM, Hari Kodungallur<hkodungallur_at_gmail.com> wrote:
>
> On Tue, Jul 28, 2009 at 1:56 PM, Dan Stromberg <dstromberglists_at_gmail.com>
> wrote:
>>
>> We have 3 subversion repositories on a single subversion server, and
>> we want to move them to a new subversion server.
>>
>> This seems simple enough - until you start to consider all the
>> absolute external references (in branches and tags) we'd want to think
>> about updating - and we're a little skittish about updating our tags.
>>
>> I calculated that for one of the 3 repos, if we have an automatic
>> process that takes about a half hour to update one branch or tag, it'd
>> take about 9 days of continuous updating to adjust all of our
>> externals. That's kind of a long time, and I'm afraid the estimate is
>> more likely low than high.
>
> Half hour to update one branch/tag? So, you have hundreds of sub directories
> in each branch/tag and each directory has its own set of externals?
>
Including the checkout, update and checkin, yes, I think about a half
hour is a pretty safe lower bound. Yes, we have hundreds of
directories per branch/tag.
>>
>> There's also the option of generating a list of all the hostnames and
>> IP's used in our external references and stealing those hostnames
>> and/or IP's, so that the externals don't need to be updated.
>
> This is not a bad idea at all. Also, it likely is not a "list of" hostnames
> and IPs; should be just one IP and hostname. Since the 3 repos were on one
> single server, the externals should be using either the hostname of that
> server or the IP of that server.
We may do this, but I fear our IP's/hostnames aren't that consistent.
I've found 3 different ones so far, and am no where near done scanning
for them all.
>
>>
>> Has someone else already been down this road?
>>
>> I have a tool that does a reasonable job of updating external
>> references by piping them all through sed, but it's never been used on
>> this scale. If there's something in common use, I'd probably use that
>> instead. Is there something like this available?'
>
> Have you tried svnmucc? I believe there was also a script (python?) that
> could be used to update the externals. I forget it now and can't seem to
> find it.
This is the first I've heard of svnmucc. Based on its usage()
function, I'm guessing it'll set all of our externals to a fixed
value, but not take an existing (and variable) svn:externals and
change it according to a fixed pattern.
I don't see anything that was obviously an external updater at
http://subversion.tigris.org/tools_contrib.html
> Also, what are the externals actually referring to? Are they directories
> within the same repo? If that is the case, the latest svn supports relative
> URLs. If you are taking the trouble to update the externals anyway, may be
> you should make them relative URLs (wherever applicable) so that this is not
> a problem in the future.
Most of the externals are within the same repository. Some are to
other repositories.
Related topic:
- I can't check out all of our source, without going through a ton of
external references.
- I want to check out as much as a I can from the new server, update
the external references, and check back in.
- But how can I be sure that I'm checking into the new server and not
the old servrer, short of making the old server unreachable somehow?
- Do I need to do a single svn switch for each branch and tag?
- Do I need to do an svn switch for every directory having external references?
>
>>
>>
>> What are best practices on this sort of scenario?
>>
>>
>> (No, I wouldn't have architected it this way at all, but I'm afraid
>> we're stuck with it. I'd've used ant/make variables or environment
>> variables instead, and failing that symlinks instead, and failing that
>> relative external references, and failing that a DNS CNAME, or at
>> absolute worst a series of _hosts_ files for the Subversion server)
>>
>> Thanks!
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2376419
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-29 00:05:30 CEST