[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: early reflections on subversion methodology

From: <ed.wittmann_at_fiserv.com>
Date: 2005-08-12 16:33:13 CEST


-----Original Message-----
From: fgatwork@verizon.net [mailto:fgatwork@verizon.net]
Sent: Friday, August 12, 2005 8:41 AM
To: users@subversion.tigris.org
Subject: Re: early reflections on subversion methodology

I think it has been mentioned on this thread before, but much of this
discussion seems like it could be rectified by a series of properly
configured hook scripts and an admin GUI (hook scripts configured in the
GUI would be wonderful). If someone took something like SVNManager
(http://svnmanager.sourceforge.net) and added a bit more functionality
(rules and such), then much of this conversation would be moot. That
system could have rules stating what your repository structure should be,
which areas to commit or not to commit, run repository reports that could
scan your svn logs, and even (if you're really good) tell you when the
coffee is done.

The only reason I mention SVNManager is that it is what I am using. It is
a UI that allows me to not have to remember all of the svnadmin commands
and I can maintain my repository from just about anywhere. It allows me
to create a repository and configure users/groups. The rest of the
functionality would sure be nice some day, but I am not a perl/php/python
programmer, so I will have to wait for some one else to build it.

I am not a SCM guru. I will not claim to be. But the discussion here
goes back and forth between the way a 'better' (VERY subjective) SCM would
do things and the way Subversion does them. I think it appropriate when
Brane stated that Subversion does most of what you want and more. The
system is TO flexible for some people to see. It's like not being able to
see the trees because the forest is getting in our way. To many choices -
to many decisions to make - no pre-defined, fixed structure to adhere to.
I think another thread a while back had mentioned the creation of a second
document to supplement the good book. Something about a 'best practices'
or 'alternative practices'
where there are samples of different uses of the system. The discussion
focused around the idea that the /trunk,/branches,/tags layout and
examples did not necessarily make for easy understanding for people who
didn't develop in this way.

just another 2 cents from me...


Branko Čibej wrote:

> A.T.Hofkamp wrote:
>> Hello all,
>> Branko Čibej wrote:
>>> BTW, because it lets you define branch and tag namespaces in any way
>>> you want, Subversion's way is _more_ flexible than most other VC
>>> systems I've seen. I think people are just irrationally afraid of
>>> this genericity and flexibility.
>> I don't think 'irritionally afraid' would be the correct term, I'd
>> call it 'getting lost in the ocean of possibilities'.
> Well, O.K. :-)
> [...]
>> Having a set of standard procedures for the standard things would go
>> a long way. A kind of user guide for using a version management system.
>> In the svn-book, and many other books about SCM, the command to
>> create or merge a branch is given, the command to create a tag is
>> given, but the procedure as a whole is not (the 1 line command is
>> kind of the end result of following a procedure).
>> For example, to create a branch (and I have never done this in real
>> life with svn, so don't assume that the procedure below makes any
>> sense):
>> (assuming project/{trunk,branches,tags} repository layout):
>> 1. come up with a nice name for your new branch (assuming 'newname')
>> 2. check that the name is not in use in /project/branches 3. copy the
>> trunk to the branch
>> svn copy ..../project/trunk .../project/branches/newname 4. make a
>> tag to merge back to the trunk against later
>> svn copy ..../project/branches/newname \
>> .../project/tags/newname-branch-<repo-number>
>> While this is not earth moving in any way, it does make these
>> procedures (and use of svn/SCM in general) more tangible for
>> new/inexperienced users.
>> (ie such procedures create a nice starting point, an island in the
>> ocean imho).
> (BTW, the SVN book does recommend a certain repository layout.)
> So, basically what you'd like is a book that would be called called
> "Configuration Management with Subversion", possibly as Volume 2 of
> "Version Control with Subversion"; is that a close guess?
> -- Brane
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 12 16:35:31 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.