>> *) The Subversion concept of a tag is that it is a directory (in HEAD).
>> While other VCS uses a concept of tags which is a revision number (or a
>> path and a revision number).
>>
>> The proposed solution of putting tags as special properties solves all
> of
>> them.
>
> It doesn't, and without major API changes to properties it couldn't work.
> Your proposed solution was not very well thought out. Look at the Apache
> repository at http://svn.apache.org/repos/asf. There are 39 different
> projects. How could you store all of the tags in revision 0 of the
> repository root and have the feature work and have meaning?
You are confusing the original suggestion of using revision properties on
revision 0, with the one we now are discussing (suggested in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=117272).
All Apache projects will have their own tag namespaces, defined as
non-revision properties on (typically) the project/branch directory. (The
proposed implementation stores tags pr branch, but now I think tags should
be stored pr project.)
> Doing
> something like Subclipse where the properties are stored as versioned
> properties within the repository would work conceptually but there are a
> lot of real API hurdles to overcome before that could be done. It might
> be worthwhile to head further down this path and work up a real design,
> but I have a feeling that to implement this "tag" feature you would have
> to dive into large thorny areas like changing how properties work.
Using non-revision properties makes them versioned.
Would you care to mention the difficulties with properties? All I can
think of is:
1. It is not possible to commit changes to single property on a
file/directory.
2. It is not simple to search properties based on their values. Or sort
the properties based on their values.
> When all is said and done, the problem is that there are a large number of
> people, myself included, that do not really think anything is broken and
> needs to be fixed. We know it is different in some ways, but we like
> those differences. If you can "bridge the designs" without compromising
> what we like, then great.
That's the goal. I just have to figure out which designs you like. :-)
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 1 16:39:45 2006