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

Re: Tags

From: Ben Collins-Sussman <sussman_at_red-bean.com>
Date: 2006-06-30 22:49:44 CEST

On 6/30/06, hakon@ion.no <hakon@ion.no> wrote:

> Note the similarity of this solution to the current Subversion-like tags.
> But instead of copying a TARGET@REVISION directory to a directory (named
> TAG) in the tags directory, the REVISION is stored as the property value
> of a property name TAG on the TARGET. And so it is easy to implement, and
> not too different from Subversion-like tags.

OK, you're proposing that the 'tagname' be a piece of metadata
attached to TARGET@REVISION, rather than making a cheap copy

What's confusing here is that you're offering a solution to something,
but nobody seems to understand what that something is. What's the
problem you're trying to solve? Before you can propose technical
solutions, you need to persuade us that there's a problem with
subversion's current tagging system.

> As a side note I would like to get feedback on: One of the "problems" with
> the notion that a tag is a full directory tree snapshot, is that it is
> impractical to fully checkout the tags directory of a large project. I
> estimate that a (full) checkout of Linux's tags directory (would have)
> amounted to about 100 GB. Storing the tag as a full directory tree is of
> course unneccesary, as the code has already been committed as
> TARGET@REVISION. The above solution does not have this defect.

As someone already mentioned, why would one ever "checkout all tags"?
And even if somebody wanted to do that, wouldn't they get a ridiculous
amount of data no matter what SCM they were using?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 30 22:50:09 2006

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