RE: RE: Re: Simple Label=RevisionID Discussion

Felix,

I reckon people like to check out an entire repository because its easier than tailoring their checkout to a specific set of projects and branch sub-folders - or at least it ought to be. Since disk space is cheap, and file and folder copies are stored efficiently in the repository, then it ought to be quick and easy to check out and update the entire repository, and not have to worry about tailoring exactly which parts of the repository to check out. It's a weakness in Subversion that this is sadly not the case - updating an entire project is far, far slower than it ought to be. I suspect that the reason many people have a checkout strategy as you've described is precisely because the easier alternative is just too painfully slow.

As you suggest, I also work on only a subset of the repository, but the problem still exists. The project I'm currently working on has become fairly large, so I only have the trunk and one branch checked out. For the most part, the small group of developers also working on this trunk tend to keep to their own sub-folders of interest and responsibility, but we frequently overlap, working anywhere within the trunk as required. One of those sub-folders contains a fairly large set of database script files, and it would be nice to be able to label this sub-folder before I embark on any substantial changes to the scripts. I would consider these labels to be my own, private labels, that don't really concern any of the other developers working in the same trunk. At the moment, if I create such a label using a local tag, every other developer working on the trunk gets a copy of this when they next update, which takes quite a long time because the scripts are large. As a direct result of this, I have resorted to
 using a .csv file to record the labels, with each label name mapped to the corresponding revision number. Other developers in my team have their own, similar ad-hoc solutions. It would be nice to able to use labels to serve this purpose.

As I see it, there are two problems with tags for this particular purpose.

1. Tags are not truly lightweight. Yes, they hardly take up any space in the repository. Yes, disk space is cheap and plentiful, so it doesn't matter too much that they take up a lot of space in the working copy. The problem is network traffic. It's bad enough having to wait minutes to perform certain updates when I'm working on my company's relatively speedy internal network. When I connect in using the VPN, it can take hours to perform some of these updates. [Surely it's possible to optimise such an update - if the update includes fetching a copied folder or file, and I already have the original on which the copy was based, can the local copy not be constructed locally, based on the originals and relatively compact deltas?]

2. A tag is a copy, not a label. A number of people have drawn the analogy that a tag is like a photocopy or a snapshot of a folder. Well that's fine, but if the folder is large, then so is the snapshot, and if the snapshot takes place inside a trunk (or branch), then everyone working on the trunk is forced to get a copy of the snapshot when they next update. In contrast, a label would be like a little post-it note stuck to the repository. Every developer working in the trunk or branch will be unaware that the post-it is there, unless they explicitly search for it, and none of them has to waste time fetching an unnecessary copy of the snapshot when they next perform an update.

Regards,

Chris

-----Original Message-----
From: Felix Gilcher [mailto:gilcher@exozet.com]
Sent: 24 November 2006 16:53
To: Chris Lambrou; Subversion Users
Subject: AW: RE: Re: Simple Label=RevisionID Discussion

Chris Lambrou <mailto:Chris.Lambrou@grantadesign.com> schrieb am Freitag, 24. November 2006 17:35:

>
> I can see such labels replacing tags in some respects. For example,
> in my development team we create a complete 'testing' build every
> couple of weeks (each time some new testable functionality has been
> completed and can be released to our testing partners). Each one of
> these builds gets tagged, and whilst this copy operation is
> inexpensive as far as the SVN repository is concerned, it is painful
> for clients to perform an update on the project root folder, as each
> tag occupies nearly half a gigabyte.
> It's a brave developer who chooses to perform a clean checkout of our
> repository. I'm considering replacing the tagging operation in favour
> of a simple log file that ties together each testing build name and
> number to its associated revision number. It would be much more
> convenient for us if this information could be recorded as individual
> labels of the trunk folder.

Why the heck do people always insist on checking out a whole repository? Check out the branch you're working on and not a single file more. If you're working on two branches at the same time, check out those two. Remove all working copies you don't need any more or use svn switch to update them to the branch/tag you'd like to test. Don't check out the whole "tags" directory unless you have a very compelling reason. svn is specifically designed to allow checking out arbitrary subsets of a repository...

regards

felix

--
Felix Gilcher
Head of IT Development
Exozet Berlin GmbH
Rotherstraße 20
10245 Berlin
eMail: gilcher@exozet.com
URL: www.exozet.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org