You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Adams <jx...@ualr.edu> on 2014/06/06 23:05:19 UTC
Moving repositories up a level
Hi, folks,
I've been asked to move some repositories up to root level.
At first, I thought this was fairly simple--dump the repositories,
edit the dump move them back in. Then I realized I wasn't sure what to do
with this entry in the dump:
Node-path: APPLICATION
Node-action: add
Node-kind: dir
Prop-content-length: 10
Content-length: 10
PROPS-END
The entries like this I just edit APPLICATION/ out of:
Node-path: APPLICATION/branches
Node-action: add
Node-kind: dir
Prop-content-length: 10
Content-length: 10
PROPS-END
And the lines like this get the same treatment:
ARGOS/tags/something.exe
But what about that top one? Do I just remove it--the whole enchilada,
from Node-path: to PROPS-END--in all cases? Or not? And if not, what do I
do? And how do I tell the difference?
Thanks,
John A
Re: Moving repositories up a level
Posted by John Adams <jx...@ualr.edu>.
Thank you! I had done considerable research on this (or so I
thought--searching on "splitting" rather than "moving" turns out to be much
more helpful). This is what I'd been using as a guide:
http://blog.tinned-software.net/splitting-up-an-svn-repository/ I've done
the dump/filter/load cycle a few times and found it to be rather simple,
with the exception of not knowing whether to remove the particular case I
was asking about. I'm trying to reason that out and may just have to take
my best shot and ask our developers to become QA analysts for a bit.
Thank you also for the advice against moving the repositories to root
level. I'll read the advisory carefully (I just skimmed it) and talk to my
team lead about it. He's considerably more experienced at this than I am.
It's possible we're doing this at the request of the developers who are the
main users of the system. We'll have to balance this security issue--which
seems to be limited to degraded access--against their needs. We have a
related problem for which I think will be fixed by upgrading from 1.8.0 to
1.8.8/9, which is on our agenda right after building a test system.
You are quite right that my question was poorly-formed, partly because (for
a pleasant change) I'm doing something with which I have virtually no
experience and partly because I was working from a laptop in a building
near my office due to a power outage. My problem, of course, shouldn't be
y'all's. This is also one of the only two applications for which I have no
test or development system to play around with, so I'm not able to do what
I would normally do, experiment and find out. My apologies for not making
my efforts and constraints clear. That's an important step which I forgot.
Thanks,
John A
P.S. Ask me sometime over a beer about my ridiculous twelve-year-old grudge
against ESR.
On Fri, Jun 6, 2014 at 5:53 PM, Ben Reser <be...@reser.org> wrote:
> On 6/6/14, 2:41 PM, John Adams wrote:
> > Come to think of it, I should specify that I'm moving a repository
> formerly
> > like this:
> >
> > http://svn.server.example.com/dev/APP
> >
> > to
> >
> > http://svn.server.example.com/dev/APP
>
> I'm guessing you mean:
>
> http://svn.server.example.com/dev/APP
>
> to
> http://svn.server.example.com/APP
>
> > when the file system is
> >
> > /data/svn/repos/dev #contains APP, APP1, APP2, app cetera
> >
> > and is now to look like
> >
> > /data/svn/repos/APP # soon to be followed by APP1, APP2, and so on
> >
> > so eventually we can rm -rf /data/svn/repos/dev
>
> Which is consistent with what you're saying here.
>
> I would advise against doing this. We have had numerous bugs over the
> years
> with repositories hosted at the root of the server.
>
> This issue from back in February is a good example of how these sorts of
> issues
> crop up (yes that's a security issue):
> http://subversion.apache.org/security/CVE-2014-0032-advisory.txt
>
> Our test suite does not cover this scenario and it's not likely to do so
> because it makes the setup for it subject to conflicts with people wanting
> to
> run it against already installed setups. So we're almost certainly bound
> to
> create bugs around this in the future.
>
> So my recommendation would be to avoid this sort of setup and always root
> the
> Location for svn at some path, e.g.
> http://svn.server.example.com/svn/repo1 etc..
>
> As to your original question. Are you saying that you're splitting the
> repositories out of a repository named dev that had multiple projects in
> it.
> In that case you probably need to dump, filter the dump for the paths that
> matter, and the load. Based on your question it looks like you're trying
> to
> just take the dump and modify it by hand which you might need to do some
> of if
> the filtered dump still has issues but I wouldn't start with hand
> modifying it.
>
> If you Google for "splitting subversion repositories" you'll find lots of
> people explaining how they've done this.
>
> Finally, I'd suggest you take a look at ESR's How to Ask Questions FAQ,
> especially the section on being precise and informative:
> http://www.catb.org/esr/faqs/smart-questions.html
>
> I point you in that direction not to be dismissive of your question, but
> to try
> and help you get more from the list. The emails you've sent in many cases
> might not have received any response at all because it's hard to understand
> what you're trying to ask.
>
Re: Moving repositories up a level
Posted by Ben Reser <be...@reser.org>.
On 6/6/14, 2:41 PM, John Adams wrote:
> Come to think of it, I should specify that I'm moving a repository formerly
> like this:
>
> http://svn.server.example.com/dev/APP
>
> to
>
> http://svn.server.example.com/dev/APP
I'm guessing you mean:
http://svn.server.example.com/dev/APP
to
http://svn.server.example.com/APP
> when the file system is
>
> /data/svn/repos/dev #contains APP, APP1, APP2, app cetera
>
> and is now to look like
>
> /data/svn/repos/APP # soon to be followed by APP1, APP2, and so on
>
> so eventually we can rm -rf /data/svn/repos/dev
Which is consistent with what you're saying here.
I would advise against doing this. We have had numerous bugs over the years
with repositories hosted at the root of the server.
This issue from back in February is a good example of how these sorts of issues
crop up (yes that's a security issue):
http://subversion.apache.org/security/CVE-2014-0032-advisory.txt
Our test suite does not cover this scenario and it's not likely to do so
because it makes the setup for it subject to conflicts with people wanting to
run it against already installed setups. So we're almost certainly bound to
create bugs around this in the future.
So my recommendation would be to avoid this sort of setup and always root the
Location for svn at some path, e.g. http://svn.server.example.com/svn/repo1 etc..
As to your original question. Are you saying that you're splitting the
repositories out of a repository named dev that had multiple projects in it.
In that case you probably need to dump, filter the dump for the paths that
matter, and the load. Based on your question it looks like you're trying to
just take the dump and modify it by hand which you might need to do some of if
the filtered dump still has issues but I wouldn't start with hand modifying it.
If you Google for "splitting subversion repositories" you'll find lots of
people explaining how they've done this.
Finally, I'd suggest you take a look at ESR's How to Ask Questions FAQ,
especially the section on being precise and informative:
http://www.catb.org/esr/faqs/smart-questions.html
I point you in that direction not to be dismissive of your question, but to try
and help you get more from the list. The emails you've sent in many cases
might not have received any response at all because it's hard to understand
what you're trying to ask.
Re: Moving repositories up a level
Posted by John Adams <jx...@ualr.edu>.
Come to think of it, I should specify that I'm moving a repository formerly
like this:
http://svn.server.example.com/dev/APP
to
http://svn.server.example.com/dev/APP
when the file system is
/data/svn/repos/dev #contains APP, APP1, APP2, app cetera
and is now to look like
/data/svn/repos/APP # soon to be followed by APP1, APP2, and so on
so eventually we can rm -rf /data/svn/repos/dev
On Fri, Jun 6, 2014 at 4:21 PM, John Adams <jx...@ualr.edu> wrote:
> In particular, what do I do with entries like this in a DELETE
> statement?
>
> Node-path: APPLICATION
> Node-action: delete
> Content-length: 0
>
> There's no additional Node-path entry to locate the file to be
> deleted. Is that just set by the import?
>
>
>
> On Fri, Jun 6, 2014 at 4:05 PM, John Adams <jx...@ualr.edu> wrote:
>
>> Hi, folks,
>>
>> I've been asked to move some repositories up to root level.
>>
>> At first, I thought this was fairly simple--dump the repositories,
>> edit the dump move them back in. Then I realized I wasn't sure what to do
>> with this entry in the dump:
>>
>>
>> Node-path: APPLICATION
>> Node-action: add
>> Node-kind: dir
>> Prop-content-length: 10
>> Content-length: 10
>>
>> PROPS-END
>>
>> The entries like this I just edit APPLICATION/ out of:
>>
>> Node-path: APPLICATION/branches
>> Node-action: add
>> Node-kind: dir
>> Prop-content-length: 10
>> Content-length: 10
>>
>> PROPS-END
>>
>> And the lines like this get the same treatment:
>>
>> ARGOS/tags/something.exe
>>
>> But what about that top one? Do I just remove it--the whole
>> enchilada, from Node-path: to PROPS-END--in all cases? Or not? And if not,
>> what do I do? And how do I tell the difference?
>>
>> Thanks,
>>
>> John A
>>
>
>
Re: Moving repositories up a level
Posted by John Adams <jx...@ualr.edu>.
In particular, what do I do with entries like this in a DELETE
statement?
Node-path: APPLICATION
Node-action: delete
Content-length: 0
There's no additional Node-path entry to locate the file to be
deleted. Is that just set by the import?
On Fri, Jun 6, 2014 at 4:05 PM, John Adams <jx...@ualr.edu> wrote:
> Hi, folks,
>
> I've been asked to move some repositories up to root level.
>
> At first, I thought this was fairly simple--dump the repositories,
> edit the dump move them back in. Then I realized I wasn't sure what to do
> with this entry in the dump:
>
>
> Node-path: APPLICATION
> Node-action: add
> Node-kind: dir
> Prop-content-length: 10
> Content-length: 10
>
> PROPS-END
>
> The entries like this I just edit APPLICATION/ out of:
>
> Node-path: APPLICATION/branches
> Node-action: add
> Node-kind: dir
> Prop-content-length: 10
> Content-length: 10
>
> PROPS-END
>
> And the lines like this get the same treatment:
>
> ARGOS/tags/something.exe
>
> But what about that top one? Do I just remove it--the whole
> enchilada, from Node-path: to PROPS-END--in all cases? Or not? And if not,
> what do I do? And how do I tell the difference?
>
> Thanks,
>
> John A
>