[clc-devel] Subversion test repo at clc.berlios.de
Hi, I've just enabled the crontab job to sync per's base and opt and our contrib to the subversion repository at CLC. The repository can be browsed here: http://svn.berlios.de/viewcvs/clc/x86/tags/CRUX-2_1/ Every change in Per's CVS HEAD and ports tagged as CONTRIB-2_1 should appear there as well. Please complain if they don't (and if you care about it ;-)). Note that the sync is once per hour only. I also wrote a ports(8) driver for subversion, available at http://jw.tks6.net/files/crux/svn.driver Thanks Tilman for testing and suggestions. Finally, the "supfiles" for your /etc/ports: http://jw.tks6.net/files/crux/base.svn http://jw.tks6.net/files/crux/opt.svn http://jw.tks6.net/files/crux/contrib.svn After installing those, ports -u will update from the subversion repository, too. We'll need some more output filtering to make it look just like subversion, but for now I couldn't care less :-). If your svn repository requires username/password, set the 'USER' and 'PASS' variables in your "supfile": URL=https://some.host/svn/repos/ports/trunk COLLECTION=internal ROOT_DIR=/usr/ports/svn USER=joeuser PASS=secret That said, I plan to test importing/merging the sparc tree against this subversion tree soon, hopefully tomorrow, and will write a wiki page describing all this. Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 04/14/05 14:25 Johannes Winkelmann wrote:
Hi,
Hi,
I've just enabled the crontab job to sync per's base and opt and our contrib to the subversion repository at CLC. The repository can be browsed here: http://svn.berlios.de/viewcvs/clc/x86/tags/CRUX-2_1/
Every change in Per's CVS HEAD and ports tagged as CONTRIB-2_1 should appear there as well. Please complain if they don't (and if you care about it ;-)). Note that the sync is once per hour only.
I'm using it on my notebook and everything seems to work fine, I really hope this tests would give a spin to a possible CVS->SVN transition at CLC. (although I suspect we'd have to hypnotize Per to make him love the change)
That said, I plan to test importing/merging the sparc tree against this subversion tree soon, hopefully tomorrow, and will write a wiki page describing all this.
Good. I'm working on a static (binary?) svn port, as stripped as possible, as a cvsup counterpart for people who wants to avoid installing the entire svn tools and deps. Maybe with a new binary name; I like 'svnup' even if it's already taken ( http://svnup.tigris.org/ ) Regards, Simone -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Hi, On Thu, Apr 14, 2005 at 19:45:22 +0200, Simone Rota wrote:
On 04/14/05 14:25 Johannes Winkelmann wrote:
Hi,
Hi,
I've just enabled the crontab job to sync per's base and opt and our contrib to the subversion repository at CLC. The repository can be browsed here: http://svn.berlios.de/viewcvs/clc/x86/tags/CRUX-2_1/
Every change in Per's CVS HEAD and ports tagged as CONTRIB-2_1 should appear there as well. Please complain if they don't (and if you care about it ;-)). Note that the sync is once per hour only.
I'm using it on my notebook and everything seems to work fine, Cool
I really hope this tests would give a spin to a possible CVS->SVN transition at CLC. (although I suspect we'd have to hypnotize Per to make him love the change) I think the transition only makes sense if we can merge between multiple architectures/platforms. From my tests with xsvn, I got the impression that this could be easily done. While I don't mean to push xsvn, I imported it into berlios' subversion repository to allow you guys to start playing with it: http://svn.berlios.de/viewcvs/clc/tools/xsvn/trunk/
In addition, I've started a page on all that, but I didn't really come to a point where I could call it finished :-) http://clc.morpheus.net:6999/clc/wiki?p=SubversionTestRepo I think a solution with subversion would be quite good for us, since it's certainly the most common OSS VCS with centralized repository; the distributed cousins all lack a way to enforce a properly merged central point to access a collection without having a dedicated patch monkey. Given our requirements, this seems pretty important to me.
That said, I plan to test importing/merging the sparc tree against this subversion tree soon, hopefully tomorrow, and will write a wiki page describing all this.
Good. I'm working on a static (binary?) svn port, as stripped as possible, as a cvsup counterpart for people who wants to avoid installing the entire svn tools and deps. Cool, that's great!
Maybe with a new binary name; I like 'svnup' even if it's already taken ( http://svnup.tigris.org/ ) I really like Jay's 'sipup' :-). I don't think the name has to be similar to cvsup. I think it would be a good idea to have a binary name different than 'svn', to allow people to break they're svn ports (e.g. by using release candidates etc) without breaking port updates. I'd even go as far as to discourage users to use this binary for other svn checkouts (even though a light client only version of subversion would be a nice addition to the ports tree). 'svup' sounds friendly to me.
Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
On 04/15/05 11:42 Johannes Winkelmann wrote:
I really like Jay's 'sipup' :-). I don't think the name has to be similar to cvsup.
Well, we have httpup and cvsup, so svnup seemed the obvious choice to me ;)
I think it would be a good idea to have a binary name different than 'svn', to allow people to break they're svn ports (e.g. by using release candidates etc) without breaking port updates. I'd even go as far as to discourage users to use this binary for other svn checkouts (even though a light client only version of subversion would be a nice addition to the ports tree). 'svup' sounds friendly to me.
Yes, I'd also take an additional step and suggest people who already have the standard svn installed to use the dedicated tool anyway for port updates, this way: - there's no need to detect what's installed within the ports driver - standard tool == quicker identification of problems The port is ready, do you prefer a binary port or a source based one that uses the included libraries? (both produce a statically linked* svup binary). Regards, Simone * to a certain extent, since it requires a binary-compatible glibc version for some calls (i.e. dlopen) -- Simone Rota WEB : http://www.varlock.com Bergamo, Italy MAIL: sip@varlock.com
Johannes Winkelmann <jw@tks6.net> [2005-04-14 14:25]:
I also wrote a ports(8) driver for subversion, available at http://jw.tks6.net/files/crux/svn.driver
Why do we need to specify $COLLECTION in the blah.svn file? Why not do it the same way httpup handles it (basename of the ports file minus the extension)? -- Regards, Tilman
Hi, On Tue, Apr 19, 2005 at 13:15:35 +0200, Tilman Sauerbeck wrote:
Johannes Winkelmann <jw@tks6.net> [2005-04-14 14:25]:
I also wrote a ports(8) driver for subversion, available at http://jw.tks6.net/files/crux/svn.driver
Why do we need to specify $COLLECTION in the blah.svn file? Why not do it the same way httpup handles it (basename of the ports file minus the extension)? We could certainly do that, even though httpup doesn't consider the filename but just the ROOT_URL. Basically, the format isn't cast in stone anyway, since I'd consider extending it to allow synchronisation of mulitple collections (much like cvsup does). It seemed that a little redundancy wouldn't hurt, but I'm not attached to the current format at all :-).
Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
Johannes Winkelmann <jw@tks6.net> [2005-04-19 14:01]:
On Tue, Apr 19, 2005 at 13:15:35 +0200, Tilman Sauerbeck wrote:
Johannes Winkelmann <jw@tks6.net> [2005-04-14 14:25]:
I also wrote a ports(8) driver for subversion, available at http://jw.tks6.net/files/crux/svn.driver
Why do we need to specify $COLLECTION in the blah.svn file? Why not do it the same way httpup handles it (basename of the ports file minus the extension)? We could certainly do that, even though httpup doesn't consider the filename but just the ROOT_URL. Basically, the format isn't cast in stone anyway, since I'd consider extending it to allow synchronisation of mulitple collections (much like cvsup does). It seemed that a little redundancy wouldn't hurt, but I'm not attached to the current format at all :-).
I see, thanks for the clarification. -- Regards, Tilman
Johannes Winkelmann <jw@tks6.net> [2005-04-14 14:25]:
I also wrote a ports(8) driver for subversion, available at http://jw.tks6.net/files/crux/svn.driver
- echo "$ROOT_DIR/$COLLECTION is not a subversion; deleting" + echo "$ROOT_DIR/$COLLECTION is not a subversion repository; deleting" :) -- Regards, Tilman
Hey, On Tue, Apr 19, 2005 at 13:52:49 +0200, Tilman Sauerbeck wrote:
Johannes Winkelmann <jw@tks6.net> [2005-04-14 14:25]:
I also wrote a ports(8) driver for subversion, available at http://jw.tks6.net/files/crux/svn.driver
- echo "$ROOT_DIR/$COLLECTION is not a subversion; deleting" + echo "$ROOT_DIR/$COLLECTION is not a subversion repository; deleting" s/repository/working copy/g ;-)
Updated now, thanks! Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net
participants (3)
-
Johannes Winkelmann -
Simone Rota -
Tilman Sauerbeck