Leon Zandman wrote:
>>You can enforce the read-write policy through hooks which are
>>server side, so this no big problem.
>
>
> Yes, but I was reacting to Thomas' statement in which he said he needed
> to solve it client side only. I don't agree with that. Server-side hooks
> are also needed to solve his issues. So I think enforcement should
> happen at both server and client side.
>
> Greetz,
>
> Leon Zandman
I did originally imply that branches/tags/workflow might be
implementable on the client-end (undoubtedly is, in some fashion), but
to be honest, I wouldn't do it that way - I believe it should be an
optional server-side layer. If you have it in, then everyone using your
system gets the same process (and whatever optionality that implies - it
might be very configurable); it should be command-line drivable, and its
semantics should be bullet-proof (no danger of wrong URLs, merge issues
as pointed out on this thread etc). Consider: we already have clear
semantics of file versioning, and a (as far as I can tell) bullet-proof
implementation of it in svn 1.2. Why would we accept less than clear
semantics and partial implementation of the next layers of functionality?
My plea to the group would be to get away from the idea that this
discussion is about subversion-bashing, and just to think about how some
bullet-proof server-side additions to SVN could be made to do what at
least some of us want.
Let's consider that the svn developers have done a very fine job with
versioning, and shown some basic ideas of how to accommodate branching
etc; but let's assume it is another task to build on this (or change it)
to finish the job for branch/tag/release/merge management.
The first step in my view (as a software engineer;-) is to develop a set
of requirements statements. I will be happy to produce some ideas in
this vein when back from holidays in a week's time, but I would like to
see requirements from some of the other people who clearly have
experience in the CM area.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Aug 1 17:50:51 2005