Re: SVN Evaluation -- Lacks CVS Module equivalent

On 2006-07-03 09:26:21 -0400, Lane Brooks wrote:
> Since the goal of SVN is to be a compelling replacement for CVS, I
> thought you might be interested in why we have decided not to switch
> away from CVS. Please redirect this message to /dev/null if you do not
> care. This is purely an informational email only.
>
> We need the equivalent functionality of CVS Modules. We organize our
> repo by functionality and then use CVS Modules to create projects that
> pick-and-choose the appropriate library code. This allows us to share
> our library code effectively.

sounds like someone read my cvs modules howto^^

> We found that svn:externals was not sufficient for us because it
> requires hard-coding the protocol. We could probably live with absolute
> directories, but access to the repository is not consistent across all
> our users.

and you can not unify the access methods?

> We also found that svn:externals causes a severe performance
> penalty ...

many svn commands support --ignore-externals. that speeds up again.

> ... and commits do not recurse into them.

not recursing into them is a feature not a bug. imagine the following
setup:

[[[
svn co url myproject
svn ps svn:externals "somelib url/upstream/somelib" .
svn up
]]]

for testing i patch stuff in somelib. i dont have write permissions for
somelib nor do i want my testing stuff be submitted there.

if svn now would forcefully recurse into externals i would get a failed
commit all the time. if you want to commi the current project _and_ the
external you can easily do:

svn commit . somelib

> We considered implementing such a feature ourselves to give back to the
> community, but after searching through the mailing archives we see that
> this has been a feature request for *many* years and that several others
> have already submitted patches that have not been incorporated. It
> appears that this feature is not even on the radar of the svn developers.

svn:internals were discussed for 1.5/2.0 iirc. but there was no 100%
conclusion howto implement them. I think noone would complain if you
finish the design of svn:internals and implement them. :)

> We have been using CVS for a many years. We would love to switch to
> something that overcomes its short-comings, but SVN is not the answer
> for us. Thus, our evaluation of the SVN found it not be a "compelling
> replacement for CVS."

your call. but i still feel more pain when using cvs.

i think in an controlled environment it shouldnt be too hard to force
one access method.

A workaround might be:
set the default properties to the most commonly used protocol.
disallow committing prop-changes to svn:externals except to a few
people.

the users now can change the properties in their working copy without
accidently committing them and breaking stuff for others.

downside of course: only a few admins can change the global defaults.

just my 2 cents

    darix

-- 
           openSUSE - SUSE Linux is my linux
               openSUSE is good for you
                   www.opensuse.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org