I have tried to stay out of this but...
>> -----Original Message-----
>> From: Chris Lambrou [mailto:Chris.Lambrou@grantadesign.com]
>> Sent: Friday, November 24, 2006 10:26 AM
>> To: Felix Gilcher; Subversion Users
>> Subject: 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.
What you propose is the equivalent of checking out every label branch and
tag from a CVS repository. You would never do that.
>>
>> 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.
If you don't insist on checking out the entire repository you can do what
you want now. Create a place for each developer to create his own personal
branches. Use this branch instead of a label. Not only will you have your
start information but you can also check your work in as often as you like.
You no longer need to save a bunch of different copies of a file. Just check
it in and you have a copy in the repository. There is the added bonus that
the things you wanted to save are backed up. You used a good check-in
comment so you know exactly what you changed when and why. Now six months
later you find a bug in your work you can go back and look at why you made
changes. Then when you are done with the things you are working on merge
them back into the trunk. I know that currently there are issues with
subversion and merge tracking; however, unless your changes are small and
don't overlap others (or your are very religious about unit tests) you're
almost going to have to merge by hand anyway.
>>
>> 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?]
The problem here is that you are not checking out your project. You are
checking out every branch and/or tag you have created for your project. I
believe that subversion already uses deltas for the updates. There has also
been some discussion that indicates that with binary files the deltas can
take more time than just downloading the file. I believe that the developers
are currently working on improving the way in which subversion tracks copies
as well has how it tracks merge information. These are not trivial issues
and might take some time to complete.
>>
>> 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.
It seems the real argument here is "It's too hard for me to -- type in the
long URLS for, remember where to find, figure out what the names are -- of
my labels so I am going to just check everything out and search for it
locally. It probably is too hard for some people. That's why subversion
offers ways to augment its base functionality using: C, C++, Ruby, Python,
Perl, .... Of course it not easy or it would have already been done.
<The follow is a comment on the entire thread and NOT this particular email>
Except for the "it's too hard" arguments listed above, I still do not
understand how a tag is not a label. Oh yeah, you have to install a hook
script to keep people from turning them into branches...
Of course then you have to use conventions. But the software shouldn't force
any conventions on me but it should know what a tag is but I should have to
tell it what a tag is but I should be able to do things however I want but I
shouldn't have to setup the software to do what I want it should just work
out of the box...
I don't mean to be offensive but some of this thread just seems silly to me.
Someday will have software complex enough to figure out what I meant to do.
Until then I am going to have to be explicite.
>>
>> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 28 22:23:07 2006