RE: FW: [DESIGN] Aliases?

Folker Schamel wrote:
>> I have to say, my complaint is that people advocating the
>> "trunk/tags/branches" structure are advocating using paths to store
>> revision information, which is nonsensical to me. =20
>>=20
>> Having current development code in trunk makes sense--it's a
>> specific location in the directory structure, proceding forwards
>> through time.  Similarly, branches are copies of specific locations,
>> which exist for some (unspecified) period of time.  Tags, by
>> definition, however, are supposed to be "snapshots" of at least a
>> portion of the repository at a specific moment in time, and are not
>> supposed to be mutable.  Tags are inherently different from
>> branches, and ought to be treated as such.      =20
>>=20
>> Trunk and branches are paths for development, and it makes sense for
>> them to be treated as such.  Tags, however, are not--and so they
>> should not be.  Seems simple enough to me. =20
>=20
> The only difference between a branch and a tag I can see is
> that the content of a tag is usually immutable.
> Otherwise they share several things.
> For example, both branches of tags are mutable:
> They are created, re-defined and destroyed.

Ok, I'm confused.  Tags are immutable, but they're mutable?  To my mind,
a tag is not mutable--once created, it should not (at least 98% of the
time) be updated, and there shouldn't be any reason to remove it.
(You'll note that my original proposal required an explicit '--force'
option to alter a tag, specifically to enforce the idea that it should
not be mutable).

> And in both cases you might want to version control such operations.
> Furthermore, you want to have hierarchical namespaces
> both for branches and tags.

Why would you want hierarchical namespaces for tags?  There's no
hierarchical namespace for revision numbers.  And, frankly, the thought
of 'svn co -r proj1/releases/1/2/8 svn://example.com/repos/proj1' scares
me.  The goal was to reduce confusion, rather than increase
opportunities for it.

> So I think it is very natural to use the versioned filesystem
> both for branches and tags.

I don't.  Tags refer to a specific moment in time, rather than files on
the drive.  Moments in time don't change, at least not with our current
understanding of time.

> My impression is that at the end you want to go backwards in time
> to the more limited CVS model, because you are used to it,
> but giving up the above advantages?

No.  I want to give the users the _option_ to use the tool in a way that
makes sense, using paths to track path information, and labels to track
time.  I love SVN's branch mechanism; it just doesn't make sense to use
it for tags--it's using a bazooka as a fly swatter.  Too much power, and
not designed for the task at hand.

> Furthermore, even if some things would be inherently different,
> then this does not mean that they must not share the same underlaying
> mechanism. For example, text files and bitmap files are inherently
> different,=20
> but both are stored in files.

Yes, they share the commonality of being files.  Branches and tags don't
share that sort of relationship.  Branches are mutable, on-going
alternate development paths; tags are (supposed to be) at least a
section of the repository at a specific point in time--which is to say,
a specific revision.  You can kludge this by copying that section off
somewhere and putting a "do not touch" sign on it, but there's no
built-in guarantee that that will happen; on the other hand, recording
the revision number is guaranteed to fulfil this through anything short
of a dump-filter-load process (and could even be designed to survive
that).

> Of course, you can discuss about the user-interface,
> for example that when using the SVN command line clients
> that you have to type more than in CVS.
> but this is a different issue than the architecture.

I agree that's a different issue, and has never been part of my
argument.  Why bother bringing it up?

-David