On Mon, Sep 6, 2010 at 10:47 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Sep 06, 2010 at 10:27:46AM -0400, Allen Williams wrote:
>> I send this email out about once a month or so in what is becoming
>> the vain hope I'll get a response...
>>
>> My subversion repository is in /var/svn. Somehow (and, yes, I'm new;
>> I'm evaluating it), I've wound up with the following directory
>> structure in my subversion repository:
>>
>> /var/svn/
>> var/svn/proj1
>> var/svn/proj2
>> var/svn/proj3.
Whare are the "db" subdirectories? Do you have 3 different working
repositories, one at /var/svn/proj1, another at /var/svn/proj2,
another at /var/svn/proj3?
Remember, whatever the location of your Subversion repository, it's
just a location of a database, one that can be located with a URL used
by clients. It's name is actually arbitrary: it's association with a
particular, and with branches and tags and a trunk under it, is
entirely by convention. Any association with a particular project or
set of projects is by your convention, it is not hardcoded anywhere
except in your client configurations, that can be updated and altered
with the "svn switch" command.
>> In other words, to do a list of the repositories, I have to do:
>
> Here you say "repositories"
>
>>
>> svn listfile:///var/svn/var/svn
>>
>> to get my projects listed.
>
> ... and here you say "projects". What do you really mean?
>
> svn list does not give you a list of repositories.
> It gives you a list of folders inside of *a* repostitory.
> So it looks like there is only one repository here, directly in /var/svn.
> Inside of that repository, you have a versioned directory also called var/svn.
> And inside there you have your proj1, proj2, and proj3 folders.
That's how I'd interpret it. The switch of syntax from "/var/svn/" to
the syntax of "var/svn/proj1" is very confusing. Does our friendly
original poster mean that inside of his repo at file:///var/svn/, he
has subdirectories for his pojects called var/svn/proj1,
var/svn/proj2, var/svn/proj3, or something else equally outre?
>> I've tried to do an svnadmin dump and load with --parent-dir, and that
>> didn't work. This was the command line sequence after I had made a copy
>> of the repository in /var/svn.sav:
>>
>> svnadmin dump /var/svn.sav> old_repos
>> rm -r/var/svn/*
>> svnadmin create /var/svn
>> svnadmin load --parent-dir / /var/svn< old_repos
And this is just..... oddness. That "rm -r/svn/* obviously would not
work, due to the missing space between the "-r" and its targets.
>> But, even though I had parent-dir as / (to try to eliminate one of the
>> /var/svn's), I still got /var/svn/var/svn/projects.
Ohh, deaar. OK, you've devinitely got subdirectories in your
repository at var/svn/project1, var/svn/projects, etc.
>>
>> What is the way to do this?
>
> You want to remove the leading /var/svn components from all paths
> in the dump file. See here:
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering
> The part that starts with:
> "At this point, you have to make a decision.
> Each of your dump files will create a valid repository, but will
> preserve the paths exactly as they were in the original repository."
> is the interesting part you should read especially carefully.
Yeah..... I think you've got it. Unfortunately, this can create
serious historical preservation issues if code has started out in
"higher level" directories and been migrated around.
Allen? How bad would it be to simply move aside /var/svn/, export its
contents, and create a clean new repository with the structure you
want? I've often found it far simpler to set a cut-off date, notify
users of the rebuild, and switch to a clean new layout with a clean
new repo. It creates issues for people with un-integrated local
changes, but it can be a lot simpler than getting cute with dumping
and re-arranging components. A simple "README.txt" at the top of the
repository, and setting it to read-only mode in an "archive" location,
can be your savior here.
Received on 2010-09-07 05:06:51 CEST