After reading through the whole "Dropping Subversion" thread, it seems
to boil down into a couple issues.
1) There are some paradigms in Subversion that do not map one to one
with paradigms in source control X.
2) Subversion has some flexibility that does not exist in source control
Y, and because we have not had this in the past, we do not know how to
take advantage of this flexibility
3) It takes more effort to do operation FOO in Subversion than in source
control Z.
All of this is to be expected with a new version control system. No
matter which system you are coming from, there are some changes that
you'll have to make to your work pattern to be most effective with
Subversion (and as with any new tool).
More specifically, some of the arguments in this thread seem to be
centered around structuring your repository. Or more specifically, the
fact that Subversion does not force you to operate in any pre-determined
method. For command line tools, this is usually a blessing and for
GUI's this is usually a curse.
With the few other version control systems that do offer this amount of
flexibility, you need a controlling script in order to do something
highly specific with the command line tool. One of the weaknesses of
this approach is that the collection scripts to do these types of
operations is not well maintained. And in most cases, even finding the
script you are looking for is problematic because the author's site is
gone or fallen into disrepair. These problems should be relatively easy
to fix with the right community support.
[insert shameless plug]
One of the idea's that I've been kicking around specifically for GUI
applications, is for a schema that defines the layout of the
repository. While the un-official (possibly offical now?)
recommendation is for the "project/ tags, branches, trunk" layout (do we
have a name for this?), I am sure that someone will find a way to use
this flexibility to enhance their development model. Being able to
describe this layout so that nearly all off the shelf GUI tools work
with your custom repository appears to be a big advantage to me. This
could help in freeing groups from thinking about whether Subversion can
support their development model, and start encouraging them to come up
with new ways to enhance their development model.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 08:21:57 2004