Frank Gruman wrote:
> Your point is an interesting one, but I too would have to disagree with
> your stance of creating a 'defacto standard'. In my development
> environment, it made more sense to change the names of the directory
> structure. No one in our development team understood what a 'trunk'
> was, or branches, or tags. So we called ours Main, Beta, and Releases.
Ah - but this exactly what I want. I only used the words "trunk",
"branches" etc because that is what is in the Subversion. I of course
think that support for this kind of thing allow local naming of these
concepts. Personally, I would prefer main/branches/releases. Tags is a
different concept - they are named baselines, so should be implemented
differently. But the names don't matter. WHat matters is having:
- a mainline development space containing a file tree
- N x named branch development spaces, each of whose tree is derived
from some other file tree, usually the mainline, but need not be
- M x name release development spaces, each of whose tree is almost
certainly derived from the state of the tree in the mainline space at
some revision
- the ability to tag any state of the file tree in any of these spaces
with a symbolic name.
> Most of the work is done on Main. When we get to a build, that code
> goes to Beta so that Main line future functionality can continue while
> testing is run. If there are bugs found in testing, they get fixed on
> Beta and eventually merged into Main. Once we get to a good point
> there, things go to Releases. Only managers are allowed to make any
> changes to Releases. I could also restrict Beta, but our dev team
> rotates through Beta dev fixing and mainline dev.
This sounds like very normal and good process to me.
> It works for us. That's what I really like about Subversion. It
> allowed us to set it up in a way that made sense to us. We didn't have
> to learn some other guys' idea of what a repository structure should
> be. I control access to things through pre-commit hooks and
> mod_auth_svn. My developers have fallen in love with cheap copies. It
> took me a couple of tries, but I have integration between my
> repositories and Bugzilla, so no commit can be done without some sort of
> Bug / Issue # being attached for all of the documentation of why changes
> are made. The more I talk about it, the more I love what Subversion has
> allowed me to do.
I agree it allows a lot of things. I just feel this is one area where it
could provide cleaner (still flexible) support for process - not just
using file system directories.
> All in all, I think the subversion developers are approaching it
> properly in allowing freedom of repository layout. If you do want
> something more 'standardized', I think I saw another post referring to
> building a __client__ that enforced whatever structure you want. That's
> the beauty - you can take the server and data inside of it and put
> whatever top end on it you want. But not at the server level.
I think that one obvious way to implement what I am suggesting is indeed
in client tools.
- thomas beale
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Jul 30 14:16:39 2005