On Tue, Jul 28, 2009 at 4:05 PM, Hari Kodungallur<hkodungallur_at_gmail.com> wrote:
>
>
> On Tue, Jul 28, 2009 at 3:04 PM, Dan Stromberg <dstromberglists_at_gmail.com>
> wrote:
>>
>> 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.
>
> May be I don't undertand this well enough. Assuming the externals are
> referring to one of the 3 repos that reside on the same server, the
> possibilities are: 'localhost', '127.0.0.1', the hostname or the actual IP
> address of the server. If there is another IP address referring to another
> repository on another server, you don't need to change it because it is not
> one of the 3 repos that you are moving.
I think you understand.
The issue here is that there was another subversion server before this
one - some of those externals remain even though it no longer servers
subversion, and we've used multiple A records (or were the alternates
CNAME's? They're not in the DNS anymore) for the same host over time.
>
>>
>>
>> >
>> >>
>> >> 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.
>
> No it works on single URL. So, you still have to automate the process by
> changing the external for each and every directory. You just save the time
> required to checkout. Thats all. (Basically you don't need a working copy to
> do this)
> You will have to get each directory (svn dirs), get its externals (svn pget
> url), update the hostnames (do some sed magic) and then use svnmucc to
> update the external for that directory (svnmucc propset svn:external
> NEWVALUE URL).
This sounds like something I should look into Thanks :)
>
>>
>> I don't see anything that was obviously an external updater at
>> http://subversion.tigris.org/tools_contrib.html
>
> Yep, I looked there, but could not find anything. I may be confusing it with
> something else. I don't remember it either way :)
I vaguely recall seeing some external updaters in that URL about a
year or two ago, but I ultimately didn't use them - they all had
issues of one sort or another - that was why I wrote one. Maybe
someone cleaned up the URL.
>
>>
>> > 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.
>
> Just to do this particular task, you don't need to checkout the externals
> (using --ignore-externals in the checkout command)
Thereby getting just what's on the new server?
>
>>
>> - 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?
If I were to pursue the method outlined, would I need a lot of svn switch's?
>> >
>> >>
>> >>
>> >> 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!
>> >
>
> I forgot about another method (that I have never used -- because I have
> never needed to) that you could try. Assuming you have access to the
> repository (server side), you can dump the repository and then I believe the
> SvnDumpTool has an option (transform-prop) to fix up the externals. Please
> try it out and see if it works for you.
>
Oh, interesting.
I've copied the data using svnadmin dump | ssh svnadmin load, but
SvnDumpTool sounds pretty interesting. Why does SvnDumpTool have such
a low version number though? Does the author not trust it yet? I
don't want to take any unnecessary risks with these files.
Thanks!
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2376450
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-07-29 01:28:24 CEST