[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Copying (branch/tag), dumping, and filtering repository contents

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: 2007-09-05 17:32:22 CEST

Bicking, David (HHoldings, IT) wrote:
>>> Alright, one more time, and then I give up. I though this
>> would be a
>>> relatively simple question, but apparently I was wrong.
>> Have you experimented for yourself (using a backup copy of
>> your repository, of course) to see what happens?
> No. I am evaluating various SCM packages and don't have the resources
> to experiment that way, even if I did have a repository on which to
> experiment.

You don't have a computer with some disk space? Subversion will create
a repository in your local file system that works just the same as
server-based repositories.

> Even if I had more resources, it wouldn't help me determine
> a "best practice". It would be days or weeks of wasted effort. I
> figured out from my problems with failing to migrate VSS to SVN that
> svndumpfilter does not follow outside the specified path(s) to get
> earlier copied-in revisions. There is no request other than my own to
> implement such a feature. I expected this to be a problem for others
> besides myself when seeking to divide repositories or keep a piece while
> discarding others. It appears I'm thinking about this differently than
> most.

Yes, usually you'd keep project/trunk project/branches project/tags and
keep them all together at the project level even if you put multiple
projects in one repository and later split them out.

> Is it unusual for people to divide large repositories into smaller ones?
> Does nobody extract and archive projects no longer in active
> development? In fact, I can't find any reference to "archive" practices
> at all in the documentation. I guess the "dump all, load from recent
> revision" method is the way to go with that. Still, that is blind to
> different logical projects (folders), and some projects could be
> archived out when that isn't desired.

If you are worried about this, you could put each project in its own
repository to start with and use http access which can make all of the
URLs look the same as a single repository.

> That's why I am perplexed at the inability to extract specific paths
> (described at the tip) and get all the information back to the earliest
> revision, even if it was not in the tip path at the time it was created.
> Since that's not possible, I am looking for a repository design that
> would enable this capability. From what I can see now, with the common
> practice, I have to grab everything from "/project1" even if I just want
> to extract "/project1/branches/releaseXYZ" because it depends upon (at
> the very least) "trunk".

I think the reason you didn't get any answers on this one is that the
question doesn't make sense. If you have history in trunk, how can you
just want to extract one branch and keep history which didn't exist
there? Keep in mind that these are 'cheap' copies, not the real thing.

   Les Mikesell
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 5 17:26:40 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.