my thoughts:
- workflow/process, etc should always be enforced by the server, never the
client.
- this is an optional layer, maybe a replacement for mod_dav_svn or
something (or in addition to) that lets clients continue to use regular
Subversion tools, but they simply can't mess with the
workflow/promotion/meta-information etc without a proper client. probably
can't be used at the same time as mod_dav_svn as that would allow clients
to go around the process. optional because not everyone needs or wants
workflow.
- to clients, tagging, etc not only should appear to be immutable (even
though they're not really on the backend) but client interaction should be
such that roles/users can be defined to a state of workflow/promotion/etc.
- the server should report to clients on demand that functionality
permitted to that particular client.
- further exploitation of the bugtraq stuff for branching/tagging/building
against specific revisions based on defect numbers.
--- snip ---
>
>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 23:16:29 2005