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...
Regards,
Frank
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
Received on Fri Aug 12 14:43:39 2005