This is an announcement that a Subversion repository for Pike is now available on eureka under the following two URLs:
http://pike-svn.lysator.liu.se/ - read-only access https://pike-svn.lysator.liu.se/ - commit access
To use the https address, you need a client certificate. I've written instructions on http://mc.pp.se/svncert.xhtml how to make and use one. (CSR:s can be sent to me.) If it turns out that this is inconvenient, we can change to basic auth with name and password instead.
Please note that while it's perfectly allright to commit for test purposes, anything committed to the repository at this time _will_ be lost when I make the next conversion run, so don't commit anything "real". :-)
Feedback on server setup or problems with the repository itself is welcome.
Is (for instance $Id$) keyword expansion for files like http://pike-svn.lysator.liu.se/Pike/7.9/README-CVS something not to be expected when browsing over http and only performed in working copies?
Yes. Keyword expansion is performed on checkout, and not in the repository. You can use e.g. "svn cat" to view the file as you would get it in a working copy:
chiyo:/tmp% svn cat http://pike-svn.lysator.liu.se/Pike/7.9/README-CVS | head -1 $Id: README-CVS 32374 2007-03-12 05:07:48Z jhs $ chiyo:/tmp%
In the last episode (Sep 02), Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum said:
This is an announcement that a Subversion repository for Pike is now available on eureka under the following two URLs:
http://pike-svn.lysator.liu.se/ - read-only access https://pike-svn.lysator.liu.se/ - commit access
I am seeing occasional UUID changes on this repository, which svn-1.5.2 at least doesn't like. I'm not sure under what conditions an SVN repo will change its uuid, but you can run "svnadmin setuuid" to reset it back.
(dan@dan.11) ~/pike> svn update svn: Repository UUID 'cc1065cb-d241-c871-94c5-f3c1647e4c1c' doesn't match expected UUID 'ed60d2f2-757b-e0e5-f865-d427cc04302a'
(dan@dan.11) ~/pike> svn info Path: . URL: http://pike-svn.lysator.liu.se/Pike Repository Root: http://pike-svn.lysator.liu.se Repository UUID: ed60d2f2-757b-e0e5-f865-d427cc04302a Revision: 35376 Node Kind: directory Schedule: normal Last Changed Author: mast Last Changed Rev: 35376 Last Changed Date: 2008-09-09 17:03:02 -0500 (Tue, 09 Sep 2008)
(dan@dan.11) ~/pike> svn info http://pike-svn.lysator.liu.se Path: pike-svn.lysator.liu.se URL: http://pike-svn.lysator.liu.se Repository Root: http://pike-svn.lysator.liu.se Repository UUID: cc1065cb-d241-c871-94c5-f3c1647e4c1c Revision: 35377 Node Kind: directory Last Changed Author: grubba Last Changed Rev: 35377 Last Changed Date: 2008-09-11 06:46:13 -0500 (Thu, 11 Sep 2008)
I am seeing occasional UUID changes on this repository, which svn-1.5.2 at least doesn't like. I'm not sure under what conditions an SVN repo will change its uuid, but you can run "svnadmin setuuid" to reset it back.
That would be because I sometimes run my script which makes a new conversion from scratch based on the CVS repository. Thanks for the tip about setuuid, I'll integrate it into the script.
Unfortunately, the svnadmin installed on eureka-svn (1.4.3) does not have the setuuid command. I wonder if it's safe to simply overwrite the db/uuid file...
is it possible to upgrade svn? i thonk going to 1.6.4 should besensible if not even 1.5. in our case there are not even any compatibility issues to consider
greetings, martin.
Currently we're using the svn bundled with Solaris. Blastwave has 1.4.5. And there's always the possibility to compile one's own. But if it's just for the setuuid function it seems moot; I checked the fsfs sources, and all setuuid does is overwrite the file, so you can do that without svnadmin. Having a sharded database might be nice, but not really required as I see it. What else would we gain from 1.5/1.6 on the server?
On the client side, you can use whatever version you like of course.
pike-devel@lists.lysator.liu.se
-
Dan Nelson -
Johan Sundstr�m (Achtung Liebe!) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr