[clc-devel] Request for comments: subversion repository
Hi there, As some of you might remember, I posted a proposal how to use subversion for port maintenance: https://lists.berlios.de/pipermail/clc-devel/2004-December/000730.html I was thinking about setting up a subversion ports repo at berlios (since the clc project already has a subversion repository there), but I'd like to check first whether there's any interest from other people. So please let me know whether you're interested in testing it. For those wondering about the reasons for this, here we go: - subversion has some advantages over CVS, which make it easier to work with (e.g. disconnected add/diff/revert) - subversion repositories can be published over http, which would solve the firewalling problem several people have with cvsup - several tools exist for distributed development (svk, submaster) or patch management (transsvn) As an addition, the script I wrote would allow to maintain "slave"-ports on other architectures, where changes from a main architecture can be merged as wanted. If there's any substantial interest, I'd volunteer to initialize the repository for x86, sparc and $TESTARCH (to allow everyone playing with multiple architectures). Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On Sat, 5 Mar 2005, Johannes Winkelmann wrote:
I was thinking about setting up a subversion ports repo at berlios (since the clc project already has a subversion repository there), but I'd like to check first whether there's any interest from other people. So please let me know whether you're interested in testing it.
If there's any substantial interest, I'd volunteer to initialize the repository for x86, sparc and $TESTARCH (to allow everyone playing with multiple architectures).
I'm interested in working on a uClibc tree; while not strictly a different arch, 20% of ports need some patch against the glibc counterparts, so it could be an interesting testbed. (providing svn compiles and works on uclibc, never tried so far) In the future I'd like to have some work on a AMD64 port as well. What about base and opt ports? Will they be included in the SVN repo? I'm still a bit confused about the new port tree layout for CRUX+CLC In general, I think it would be a good idea to make the point of what's going on regarding CRUX 2.1, but this really belongs to another thread. Regards, Simone
Hey Simone, On Sat, Mar 05, 2005 at 21:26:40 +0000, Simone Rota wrote:
On Sat, 5 Mar 2005, Johannes Winkelmann wrote: [...]
If there's any substantial interest, I'd volunteer to initialize the repository for x86, sparc and $TESTARCH (to allow everyone playing with multiple architectures).
I'm interested in working on a uClibc tree; while not strictly a different arch, 20% of ports need some patch against the glibc counterparts, so it could be an interesting testbed. (providing svn compiles and works on uclibc, never tried so far)
In the future I'd like to have some work on a AMD64 port as well. Both of them are very good examples where the subversion setup _might_ save some work.
What about base and opt ports? Will they be included in the SVN repo? I'm still a bit confused about the new port tree layout for CRUX+CLC Right, this is a good remark; in order to be helpful for the SPARC port, base and opt(+contrib) should be there; it would be best if we could sync the clc tree automatically, I'm not sure yet if this can be done easily.
Otherwise, it would just be a test run, in which case I think it would be easiest to use only a few ports.
In general, I think it would be a good idea to make the point of what's going on regarding CRUX 2.1, but this really belongs to another thread. I agree, but in order to discuss this seriously, some experience would be good; if it works out as good as CVS or better, we can certainly consider the switch.
As a (rather interesting) sidenote: I'm not yet sure about the use cases we have, and how well xsvn copes with that; imagine the following: 3-arch setup, x86, x86_64, sparc: 1. a port is added to x86 2. both x86_64 and sparc ports are synced (merged from x86) Now, if the x86 port is updates, sparc and x86_64 can merge nicely, since xsvn set the revision number where it merged from. It's a bit different when the x86_64 maintainer is faster, and the x86 person would like to merge those changes; since we didn't store the branch point from x86 to x86_64, we could only try to be smart (I'm thinking about that right now...). I was wondering whether it would be okay to always require version numbers for cross-platform merges; imagine the above situation, where the x86_64 maintainer was faster with an update, and the x86 maintainer would just like to get those changes, too; in this case, the x86 maintainer would have to find out the revision number of the change (e.g. in the timeline, or via commit notification), and do something like xsvn merge-from sparc64 port -r 100 or if one would want to merge multiple changes, to an xsvn merge-from sparc64 port -r 100,101,102 Not sure if I'm clear here, but implementing a merge tracking which works bidirectional by means of svn properties is certainly not an easy task... and the explicit selection doesn't look all bad to me, since I'd expect that if we would do a simple "merge all that was changed since the last merge", we'd get some unecessary changes. Opinions, questions? Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 03/07/05 19:47 Johannes Winkelmann wrote:
What about base and opt ports? Will they be included in the SVN repo? I'm still a bit confused about the new port tree layout for CRUX+CLC
Right, this is a good remark; in order to be helpful for the SPARC port, base and opt(+contrib) should be there; it would be best if we could sync the clc tree automatically, I'm not sure yet if this can be done easily.
Expecially considering that the current uCRUX has only around 10 contrib ports :)
Now, if the x86 port is updates, sparc and x86_64 can merge nicely, since xsvn set the revision number where it merged from. It's a bit different when the x86_64 maintainer is faster, and the x86 person would like to merge those changes; since we didn't store the branch point from x86 to x86_64, we could only try to be smart (I'm thinking about that right now...). [cut] Not sure if I'm clear here, but implementing a merge tracking which works bidirectional by means of svn properties is certainly not an easy task... and the explicit selection doesn't look all bad to me, since I'd expect that if we would do a simple "merge all that was changed since the last merge", we'd get some unecessary changes. Opinions, questions?
My view: I think it's a bit dangerous (and complicated as you note) to let the different archs diverge too much or pump the updates to the x86 tree. Maybe it's the case of considering the x86 as the 'main' repository and keep the other architectures as in sync as possible with that, since: - x86 at the moment has more contributors - more users as well ==> a bit more tested Eventually the $ARCH maintainer can submit a port update for x86 to the respective maintainer if there are significant changes that are not yet in the x86 tree. Just some random thought, since we don't really have any idea at the moment about how a multi-platform CRUX community would evolve when there is an infrastructure to support it. So for now I'd opt for the easy, unidirectional way as presented above. Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Johannes Winkelmann <jw@tks6.net> [2005-03-05 13:43]:
I was thinking about setting up a subversion ports repo at berlios (since the clc project already has a subversion repository there), but I'd like to check first whether there's any interest from other people. So please let me know whether you're interested in testing it.
I'd happily help testing, too :) -- Regards, Tilman
I've always liked the idea of trying svn for ports, I'm all for a test at the least. I use it for my personal stuff and love it. Matt (jaeger@freenode/#crux)
Hi, I added some folders to the repository: http://svn.berlios.de/viewcvs/clc/ Have a look at the following document to learn how to check out files: https://developer.berlios.de/svn/?group_id=847 Unfortunately, berlios doesn't offer subversion over http, but IMHO this is a minor problem at the moment. At the risk of making this another boring mail (danm ;-)), here comes the log of my commits (after creating the initial structure): Please ask if you'd like to learn more! ## # first: add a single port to x86 mkdir /tmp/single-arch cd /tmp/single-arch svn co svn+ssh://svn.berlios.de/svnroot/repos/clc/x86/trunk cd trunk cp -r ~/crux/clc/htop . svn add -N htop cd htop svn add Pkgfile .footprint .md5sum svn ci -m "initial commit of htop" -> http://svn.berlios.de/viewcvs/clc/x86/trunk/ ## # second: merge it to sparc export XSVN_SRC_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86 export XSVN_BASE_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/sparc export XSVN_RELEASE=CRUX-2_0 mkdir /tmp/work-multi cd /tmp/work-multi svn co $XSVN_BASE_REPO/trunk cd trunk xsvn merge-from htop svn ci -m "commit htop to sparc" -> http://svn.berlios.de/viewcvs/clc/sparc/trunk/ ## # release it to base of sparc 2.0 xsvn release base htop [ editor pops up; say "add htop to sparc/2.0" ] -> http://svn.berlios.de/viewcvs/clc/sparc/tags/CRUX-2_0/base/ ## # release htop to x86 2.0 export XSVN_BASE_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86 xsvn release base htop -> http://svn.berlios.de/viewcvs/clc/x86/tags/CRUX-2_0/base/ ## # merging to x86_64 export XSVN_BASE_REPO=svn+ssh://svn.berlios.de/svnroot/repos/clc/x86_64 mkdir /tmp/work-multi-64 cd /tmp/work-multi-64 svn co $XSVN_BASE_REPO/trunk cd trunk xsvn merge-from htop svn ci -m "commit htop to x86_64" -> http://svn.berlios.de/viewcvs/clc/x86_64/trunk/ ## # and finally release htop to x86_64 2.0; opt this time xsvn release opt htop -> http://svn.berlios.de/viewcvs/clc/x86_64/tags/CRUX-2_0/opt/ ## # add it to x86_64, crux 2.1: export XSVN_RELEASE=CRUX-2_1 xsvn release opt htop That's it. xsvn is available at http://jw.tks6.net/files/crux/xsvn/xsvn make sure you're using 0.3 or higher (uploaded five minutes ago). Enjoy, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
participants (4)
-
Johannes Winkelmann -
Matt Housh -
Simone Rota -
Tilman Sauerbeck