You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stephen Kennedy <st...@gnome.org> on 2004/12/21 14:39:30 UTC
cvs modules feature missing in subversion
Hi,
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.
Thoughts?
Stephen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by Stephen Kennedy <st...@gnome.org>.
> > I'm no svn hacker but it seems as though most of this issue revolves
> > around supporting directory hardlinks inside the svn filesystem.
>
> It'll work better to consider each feature/enhancement individually
> [...] There's no overarching
> commonality to the CVS modules features, except the fact that they're
> all controlled from the CVSROOT/modules file.
Agreed, the "modules" is a bit of a red herring but at least conveys
an idea of functionality needed.
All of the mentioned issues would be solved if the filesystem supported
internal hard links between directories. File hard links would be nice
but not strictly necessary.
The functionality could be achieved by covering each of the cases mentioned
below individually, but intuitively it seems more error prone to have
to cover each case instead of letting the backend handle it.
http://article.gmane.org/gmane.comp.version-control.subversion.user/22641
So then: how about an issue for (repository) filesystem internal hard links?
Stephen.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by Shurik O <sh...@gmail.com>.
>> why doesnt it support branching and tagging? you just need to update the
>> externals in the tag/branch if needed. that doesnt sound like much work.
Well, not much work when you have a library or two. In our case, with dozens of libraries, the thing
is unmanageable without automation and we need some scripting but then, this solution is just
as easy to implement as the "vendor branches" option.
Let me be more specific.
=== What we have is ===
/trunk/
lib/
libA/
libB/
prog1/ # wants to use libA and libB
prog2/ # wants to use only libA
The purpose is to automatilly checkout only the libraries used by the respective programs.
=== Option 1: svn:external ===
would make it like:
/trunk/
lib/
libA/
libB/
prog1/
lib/ svn:externals=
svn://svnhost/svnpass/trunk/lib/libA
svn://svnhost/svnpass/trunk/lib/libB
prog2/ svn:externals=
svn://svnhost/svnpass/trunk/lib/libA
So each time we tag we should modify the svn:externals to something like:
svn://svnhost/svnpass/tags/build1280/lib/libA
...
for every library. If there are many libraries, the thing is unmamangeble without automation.
=== Option 2: Copying and merging a la "vendor branches" ==
/trunk/
lib/
libA/
libB/
prog1/
lib/
libA/ # made by 'svn copy .../trunk/lib/libA'
libB/ # made by 'svn copy .../trunk/lib/libA'
prog2/
lib/
libA/ # also copied from /trunk/lib/libA
To make this work we need to record the library source in properties or in a file. We also
need to record the last imported revision of each library:
prog1/
lib/ module:source=/trunk/lib
libA/ module:revision=...
libB/ module:revision=...
prog2/
lib/ module:source=/trunk/lib
lib1/ module:revision=...
Again, we need a script. This time to re-import all or some of the libraries in one shot. Please
note that if you rearrange the repository you will also need to update the module:source properties
to point to the new location but the change will not affect old versions -- they will still work.
Right now I like the "vendor branches" option more because branching and tagging works as it meant
to be -- you just 'svn copy'. It also makes you explicitly "import" changes in the libraries
which some may call an advantage.
I also dislike svn:externals in its current state because it locks you into specific scheme you use
to access SVN. Say you decide to switch from http:// to svn:// scheme or just moved the
repository to a diffent host -- now you are screwed because you cannot checkout versions made
with the old scheme anymore.
It seems that the name "svn:externals" well reflects its function -- to access
EXTERNAL repositories :-) Using svn:externals INTERNALLY is a hack, not even a workaround. Should
it supported intra-repository paths (like /modules/A, without the scheme-host part) and
relative paths (like ../lib1) then it may have worked better; still not perfect.
Marcus Rueckert wrote on 12/31/2004 8:09 AM:
> hi,
>
> On 2004-12-31 01:16:17 -0800, Shurik O wrote:
>
>>svn:externals is out of the question as it wouldn't support branching and
>>tagging.
>
>
> why doesnt it support branching and tagging? you just need to update the
> externals in the tag/branch if needed. that doesnt sound like much work.
>
> darix
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by Marcus Rueckert <da...@web.de>.
On 2005-01-03 09:26:37 +0100, subversion@smartcvs.com wrote:
> Now you want to tag project A to mark your version 1.0. You want to tag
> LibX, because it is part of your project and you want to be able to get
> exactly this state after some months of progress. This is the point of
> view from project A. From the LibX' point of view, it should not be
> tagged, because - well - imagine all applications using that library
> would tag it! What a mess!
that isnt a problem either. i have 2 points here:
1. normally you dont develop against trunk you release against versions.
means you specify "you need version x.y or higher"
that means you tag your app. and change the external to the tag of
the library which is supported.
2. you develop against trunk and need a specific version of libX trunk.
you can tag and point the external to the trunk@rev.
> I see only one reasonable possibility: integrate a copy of LibX ('
> sourcecode) into your project and tag that.
not really needed as you see
just my 2 cents.
darix
--
irssi - the client of the smart and beautiful people
http://www.irssi.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by su...@smartcvs.com.
Imagine following situation. There is an open source library LibX (e.g.
hosted on sourceforge - if it would support svn), which is used in an
application A.
Now you want to tag project A to mark your version 1.0. You want to tag
LibX, because it is part of your project and you want to be able to get
exactly this state after some months of progress. This is the point of
view from project A. From the LibX' point of view, it should not be
tagged, because - well - imagine all applications using that library
would tag it! What a mess!
I see only one reasonable possibility: integrate a copy of LibX ('
sourcecode) into your project and tag that.
But to be honest, CVS supports that as good as Subversion - it doesn't.
One has to synchronize the original LibX and the copy of it in project A
manually.
--
Tom
Marcus Rueckert wrote:
> hi,
>
> On 2004-12-31 01:16:17 -0800, Shurik O wrote:
>
>>svn:externals is out of the question as it wouldn't support branching and
>>tagging.
>
>
> why doesnt it support branching and tagging? you just need to update the
> externals in the tag/branch if needed. that doesnt sound like much work.
>
> darix
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by Marcus Rueckert <da...@web.de>.
hi,
On 2004-12-31 01:16:17 -0800, Shurik O wrote:
> svn:externals is out of the question as it wouldn't support branching and
> tagging.
why doesnt it support branching and tagging? you just need to update the
externals in the tag/branch if needed. that doesnt sound like much work.
darix
--
irssi - the client of the smart and beautiful people
http://www.irssi.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by Shurik O <sh...@gmail.com>.
>> 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 <st...@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
Re: cvs modules feature missing in subversion
Posted by Max Bowsher <ma...@ukf.net>.
kfogel@collab.net wrote:
> Stephen Kennedy <st...@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
Re: cvs modules feature missing in subversion
Posted by Michael Sweet <mi...@easysw.com>.
kfogel@collab.net wrote:
> ...
> 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 :-).
> ...
Can't users already just create a directory and set the svn:externals
property to simulate CVS modules?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: cvs modules feature missing in subversion
Posted by kf...@collab.net.
Stephen Kennedy <st...@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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org