John Calcote wrote:
> Vincent Starre wrote:
>
>> I really disagree strongly with the idea that tags are just
>> hacked-on. Something being a natural side-effect of a
>> well-thought-out implementation- that is, requiring /no further code
>> to work/ is a good thing, something to be praised, not a bad thing.
>
> I will admit that it's cool that tags CAN be implemented in terms of
> existing code. I never said Subversion wasn't well-designed. I was
> only stating that the concept of tags is important enough in version
> control to truly warrant its elevation to first-class status. I still
> believe this is true.
>
> Let me give you an example from my current projects. I work for Novell
> in the directory and identity spaces. In this domain, we can build
> nearly all (relevant) concepts on the fundamental entry/attribute
> model. We chose not to do so because the flexibility this affords
> would allow people to do dumb things. (Incidentally, in the directory
> and identity spaces, we call this a security hole.:) )
>
>> As for immutability, while tags represent an area which is "not to be
>> messed with", that's far from immutable. Certainly, there are some
>> tags which shoulodnt be touched, but the vast majority of tags (that
>> I use, as opposed to that exist in the repos) I use are in fact
>> "mutable". That is, they are not to be worked on, but they certainly
>> do not represent a /single/ point in time.
>
> Understood. When I used the term immutable, I was referring to the
> contents of a work area arrived at via a tag, not the tag itself.
> Clearly, there are advantages to having tags be deletable, or movable.
>
>> "built-in" support for immutability? Can't this be handled through
>> locks? (and can't locks be triggered with a hook?)
>
> Sure, and can't symbolic names for revisions be managed by putting a
> file called TAGS at the root of your project that contains a simple
> mapping of revision numbers to symbolic names? Of course, but no one
> would call this an elegant solution - even after you showed them the
> grep/sed hack. :)
>
>> I would shy from any change which would attempt to make svn "aware"
>> of the filesystem in a way which is not implemented through
>> user-defined hooks. Perhaps what is really needed is a better
>> framework for writing hooks? I'm sure such things already exist for
>> all the major languages, so maybe what's really needed is to
>> publicize such things more :)
>
> Subversion is not only already "aware" of the file system, but for
> some back-ends (Berkeley DB, for instance), it IS the file system.
> Besides, I don't really believe that tags-as-a-first-class-concept is
> going to intrude on the file system very much. This is really a
> database issue, not a file system issue. If the file system you're
> referring to is the client-side work area, then I should clarify that
> I never stated that users shouldn't be able to modify their work area
> in any way they wanted - I only said that Subversion would not allow
> comits from a work area produced from a tag. Returning to my example
> above from the directory and identity spaces - this is what I'd call
> "a dumb thing that people might do".
>
> John
When I say "the filesystem" I don't mean the OS filesystem, I mean the
versioned filesystem which Subversion is directly responsible for- I
don't think subversion itself should know anything about its structure
and what it means.
This ties directly back to what you said about people doing dumb things,
and is a sheer difference in philosophy: I think only very poor systems
prevent people from doing something stupid :)
Bare with me.. it's not entirely insane.
When you try to define "the way this works", the problem comes in trying
to please everybody. You either wind up with an inflexible system which
98% of the time needs to be ignored anyway, or you wind up with
something which is just 100% useless. Currently, anyone can implement
whatever controls for tags that they want. I would suggest the answer
isnt "pushing tags into a seperate namespace", but rather just including
more default hooks and making them more easily accessible to the average
user. In essence: since the code is already there, why not just use that
code? I don't ever see the point in re-implementing something which is
already implemented in a more robust manner than any other solution
could offer. Especially when the "old way" would still be around in
order to still support the "more robust" method- this could only lead to
confusion.
As for making it a "first class citizen", that's really a loaded term.
Tags already are just as "first class" as every other object in the
filesystem. Seperating tags, that is, adding forced constraints to them,
could only make them /less/, not more.
I agree there should be more support for warning someone when they are
about to do something stupid, but I dont think that should be done
peicemeal. If hooks aren't "good enough" for you, maybe they are what
actually need to be improved apon. I really dont think the core code
needs to be touched on the grounds of a philisophical war. All I ever
hear from those who like to pretend that SVN doesnt have built-in
support for tagging is that the current method somehow doesnt feel right
or is inelegant because it is so powerful and can suit everyone's needs
perfectly. They want the ability to be utterly limited in what they are
capable of doing. The reason I fight this is that I just don't
understand that kind of logic.
Again, in all seriousness: couldnt this be implemented using locks?
(I've not used svn's locks, so I don't know)
Please help me understand if that wouldnt be suitable. You dont want to
be able to commit to something, SVN has the ability to say "this can't
be comitted to", so why not that?
A more elegant way to access hooks, to organize hooks, to call hooks,
that might be useful. If hooks as they are are too inelegant, why not
make hooks better instead of trying to shunt everything into a new
second-class citizen whenever something that by all rights should be
implemented as a hook + filesystem combo comes up?
If it can be implemented without touching the main code, and can be done
well, why bother? If it can't, is this a limitation of the main code, or
a limitation of what !theMainCode can do?
too much random thoughts. stopping :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 21 04:24:33 2006