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

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

From: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-09-05 14:59:16 CEST

> -----Original Message-----
> From: Andy Levy [mailto:andy.levy@gmail.com]
> Sent: Wednesday, September 05, 2007 8:27 AM
> To: Bicking, David (HHoldings, IT)
> Cc: users@subversion.tigris.org
> Subject: Re: Copying (branch/tag), dumping, and filtering
> repository contents
>
> On 9/5/07, Bicking, David (HHoldings, IT)
> <David.Bicking@thehartford.com> 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. 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.

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.

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".

*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 5 14:56:31 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.