You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Lane Brooks <lb...@MIT.EDU> on 2006/07/03 13:26:21 UTC
SVN Evaluation -- Lacks CVS Module equivalent
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.
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. We also found that svn:externals causes a severe performance
penalty and commits do not recurse into them.
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.
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."
Thanks,
Lane Brooks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SVN Evaluation -- Lacks CVS Module equivalent
Posted by Marcus Rueckert <da...@web.de>.
On 2006-07-07 09:34:28 -0700, Erik Kline wrote:
> 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.
ugh why?
> 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?
no
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
Re: SVN Evaluation -- Lacks CVS Module equivalent
Posted by Erik Kline <ek...@google.com>.
On 7/7/06, Marcus Rueckert <da...@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
Re: SVN Evaluation -- Lacks CVS Module equivalent
Posted by Marcus Rueckert <da...@web.de>.
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