news <news@sea.gmane.org> wrote on 29.07.2005 11:23:16:
> 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
I see your point, but don't buy it. You argue, that the tool is bad,
because it does not force everyone to "do things the right way" (even
though the jury is still out on what "the right way" is). But this is a
generic tool, that can be easily (if not without some work) enhanced to so
exactly what you want. Or do whatever somebody else wants, in a different
way. On the other hand, if its structure was locked to your way of doing
things, than it would force all other "real developers" to do things just
one way. And maybe, by being more open, somebody will come up with an even
better way of doing things.
But beside that, if you can not make your users/developers conform to your
standards, than you have organizational problems, not software problems.
Cheers,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
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:46:51 2005