[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: Bicking, David (HHoldings, IT) <David.Bicking_at_thehartford.com>
Date: 2007-09-10 15:36:21 CEST

> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> Sent: Friday, September 07, 2007 5:42 PM
> I'll just reply to a few things:
> On Sep 7, 2007, at 11:59, Bicking, David (HHoldings, IT) wrote:
> > It appears to be impossible in SVN. The most likely scenario for
> > extracting one particular branch, all the way to the root,
> is when one
> > wants or needs to pull out the important information and
> discard the
> > chaff. The most likely situation in which this scenario
> will rear its
> > ugly head is when some poor schmuck like me comes in and
> realizes that
> > the repository was not planned, monitored, or otherwise
> controlled for
> > the previous X years. Secondary to that, is the "mistakes
> were made"
> > scenario, or "well, I didn't expect THAT business process
> change when
> > I set things up 3 years ago!".
> What aspect of having a repository not be planned, monitored
> or controlled makes it difficult for you to plan, monitor and
> control it now? You can examine the "svn log" to see what has
> gone on during the time the repository was not monitored. You
> can install post-commit email hooks to inform everybody of
> every commit from now on. If things in the repository are not
> organized the way you like, you can "svn mv" them into the
> correct place now.

... And if in five years I want to grab one or two projects out of the
repository and discard the rest, I cannot.

> It is not usual to archive old revisions. Not in Subversion, anyway.

I noticed that. Fortunately, because it is so efficient, it generally
shouldn't be necessary. I'm speaking of edge cases like the one we're
dealing with in VSS right now.

> Also, it's also not always advantageous to trim away old revisions.
> Sometimes this has the effect of making your repository
> larger on disk, not smaller. Subversion stores revisions as

Duly noted. While I'd not considered that possibility, the goal of my
questions was to pull one branch "down to the root" out of many from
multiple projects, so the situation isn't relevant to my needs.

> deltas against some previous revision, and also, copies are
> cheap in Subversion, meaning that if you have a repository

I understand the cheapness, and love it. I just don't want to be
restricted by it.

> It sounds like you're envisioning repository maintenance
> tasks which are neither necessary nor recommended nor easy.
> My advice is to forget that, and just let your repository grow.

To a point, I totally agree. Again - edge scenarios. I'm dealing with
the situation in VSS where I want to pull out a subset of code with all
its history, and cannot. It's not a devistating situation, but it is

> Of course I can't help with your corporate politics. All I
> can do is look at bestbuy.com and see that a 320GB internal
> drive costs about USD 120. Get two of those, make a RAID 1

I understand that, and agree. Thank you for your input, it is very
useful even though my needs aren't met :)

(p.s.; I got a 500GB eSATA for $120 a couple of months ago - absolutely

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 Mon Sep 10 15:33:48 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.