Steve Williams wrote:
> Thomas Beale wrote:
>
>> I have used many CM systems, and have been thinking about whether
>> subversion supports the kinds of processes needed in real development,
>> particularly release management. I think that the basic advice of
>> using the trunk/tags/branches directories is ok, but does not go far
>> enough.
>
>
> That is, "real development" in your world of real development.
> Everyone's world of real development is slightly different. The above
> statement made it sound like Subversion is a toy versioning system not
> used in "real development".
Well I would say it is a good versioned file system implementation at
this stage - very good in fact. But it doesn't have any built in support
for branching or tagging, only lazy copying, which goes a go way to
making it work, but otherwise the facility is manual. This means it is
ad hoc, and no users or tools can make any assumptions about how
branches, tags etc work.
By "real" development I just meant any development that actually has a
wide user base, issue tracking lists, change requests to document
changes, and identified releases. I'm sure you will agree that it is
perfectly possible to build (great) software without all these things;
however such limited process usually corresponds to a small closed team
(e.g. an experimental academic development) or a sole developer.
>>
>> It would be good if subversion a) supported a standard directory
>> structure like this, and b) if the tools could hide these directories
>> (at least on the client side) and instead show them as 'views' - i.e.
>> the user would be in the mainline view, the branch-xyz view, the
>> release-0.8 view and so on. I don't think it would be hard to do.
>
>
> Subversion does not impose any directory structure on you. Subversion
> supports whatever directory structure you want. If I wanted to, I could
> have a directory structure like this:
>
> - foo
> - BAR
> - pOoP
sure; and that's the problem/challenge at hand - imposing some standard
thinking on this. Consider it this way: if subversion's revisioning
really works (I mean: there are 0 bugs in the versioned representation
of files) - and as far as I can see, it is 99% there - then its
versioned representation of a directory tree is half-way to a defacto
standard representation of versioned hierarchical data. This hasn't
previously existed (well, CVS was there, but not very good at
representing changes other than to content of files; otherwise you had
closed things like VMS's versioning file system); if we went a bit
further and the community agreed a generic methodology about branching,
tagging and releasing, then that methodology could be introduced into
the tools as well. Such methodology is pretty well known in the world of
CM and is built into most commercial tools. It seems to me that
Subversion could be first off the block to both implement _and_
standardise it.
>
> and Subversion would still work as wonderfully as it does with the
> defacto standard of trunk, branches, tags. Uppercase, lowercase,
> naming. It is totally up to you.
>
> As for clients hiding those directories, you would have to customize one
> of the many available clients (they are open-source after all) since
> what you are trying to hide is your own idea of a "real development"
> directory structure.
No it's not about hiding anything, it's about how it is _represented_.
Currently it is in user-made ad hoc directory structures, which can
easily be abused by accident. I would be interested in seeing the tools
go past that situation and implement some CM features more directly.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 29 11:27:49 2005