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
TARGET@REVISION.
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