Lars Gullik Bjønnes wrote:
> Danny van Heumen <danny.vanheumen@hccnet.nl> writes:
>
> | PS: How can a better Version Control System be created if it keeps
> | getting compared with other VCS. And even to CVS which it is trying to
> | replace... If we build everything exactly the same, why build it? Just
> | use CVS :-)
>
> How can a better Version Control System be created in a vacuum? Of
> course you have to compare to other VCS, both as a source for
> inspiration, features, how to _not_ do things, but also _how_ to do
> things.
Very, very true!
As a source of inspiration for features it is always a good idea. I
always like to keep an open mind (and I hope everyone does).
As for 'how to do' or 'how not to do' things, that really depends on the
situation. As for SVN, at least this is how I understand it, the cheap
copy is a very (simple) powerful feature. Because of this feature I
think it has outgrown the CVS-like approach for tags.
Btw: I think we really really need to make a list of all pros and cons
to SVNs way of tagging/branching because this discussion is starting
every two (or so) months. I guess it will never stop until we work out
the scenarios/issues/(im)possibilities/etc.
I alone could not work out all scenarios because I don't have enough
experience with VCS. (And I haven't experienced enough companies using
VCS yet ;) )
I guess working out scenarios is also the best way to come to an
alternative approach (interface or implementation) for the developers
without comparing directly to another VCS.
*** If someone is really interested in working out some scenarios with
tags/branches, plz contact me off-the-list. ***
>
> As to devel... one (seemingly) small thing that would make life
> easier for me would be if it were possible to put a needs-lock on a
> directory.
>
Good point ;)
I guess you mean automagically putting a needs-lock on all files inside
a directory (recursively?). Or did you mean locking the directory so
that no one can alter it's svn properties? (Guess not :))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 3 01:55:51 2006