On 7/7/06, Marcus Rueckert <darix@web.de> wrote:
> 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.
Could this also be handled by a wrapper layer? 'svn_wrapper co
<module_name>' where module_name could be looked up in a config file
(see other thread Tags -> Configuration) and mapped to the current
real repo location.
Alternatively (and I'm completely ignorant of how/if this works) could
something be set up for module_name urls that 302's to the current
repository location?
random ...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 7 18:35:22 2006