>> I don't think there would be any point in having an issue saying "we
>> need an equivalent of CVS modules", but it would be wonderful if someone
>> wanted to analyse the uses to which CVS modules can be put, and generate
>> a set of case-studies of thinks which are difficult/impossible to do
>> using subversion.
Sorry, cannot offer exaustive analysis -- just one use case.
We have rather extensive library of packages and deliverables that are using each
their own subset of the library. Each deliverable has their CVS module that pulls only parts
necessary to build this deliverable. Given the significant size of the repo (>20K files) and
the slowness of SVN on big repositories (as compared to CVS; a confirmed fact in my case),
it is imperative to be able to checkout specific subset of the repository for each deliverable.
svn:externals is out of the question as it wouldn't support branching and tagging.
I am playing with a setup based on vendor branches and merging but
it requires much manual work or extensive scripting.
The proposed svn:internals may work for us but we are open to other options as well.
Granted, CVS modules have their problems too but we want Subversion to solve all CVS problems
for us without creating new ones :-)
Max Bowsher wrote on 12/30/2004 11:20 AM:
> kfogel@collab.net wrote:
>
>> Stephen Kennedy <stevek@gnome.org> writes:
>>
>>> There was some discussion on the subversion-users list about opening
>>> an issue for the CVS modules feature and it was suggested that I post
>>> to the devel list for more feedback.
>>>
>>> http://article.gmane.org/gmane.comp.version-control.subversion.user/22641
>>>
>>>
>>> There have been several posts to the list asking about this
>>> functionality.
>>> http://article.gmane.org/gmane.comp.version-control.subversion.user/22633
>>>
>>>
>>> I'm no svn hacker but it seems as though most of this issue revolves
>>> around supporting directory hardlinks inside the svn filesystem.
>>
>>
>> My feeling is that just because CVS happens to group a bunch of
>> disparate functionality into one blurry thing called "modules",
>> doesn't mean we have to see the world that way :-).
>>
>> It'll work better to consider each feature/enhancement individually
>> (which seems to be what we're doing already, based on the issue
>> numbers in the mails you refer to above). There's no overarching
>> commonality to the CVS modules features, except the fact that they're
>> all controlled from the CVSROOT/modules file.
>
>
> ... and that they are collectively a group of features we don't have
> much support for.
>
> I don't think there would be any point in having an issue saying "we
> need an equivalent of CVS modules", but it would be wonderful if someone
> wanted to analyse the uses to which CVS modules can be put, and generate
> a set of case-studies of thinks which are difficult/impossible to do
> using subversion.
>
> Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 31 10:17:50 2004