Request for Subversion upgrade

Thu Jan 3 19:33:10 UTC 2008

Hey,

I don't need convincing of the merits to running a newer subversion. 
It's a production system and we're viced by stability and contractual 
guarantees. If I were on my own it'd already be the latest version 
available.

The Sun HG repository is so sun can publish their own patches in a way 
so we can track and pull their changes. It's not meant to be an 
alternative method of tracking any of the main development trees.

However, they will have to figure out how to track from SVN. Perhaps 
they have a working method you could steal?

-Dormando

Sandeep Srinivasa wrote:
> 
> Thanks either way...
> Incidentally, the OpenSolaris guys have gone ahead and started planning 
> for a HG repository 
> (https://opensolaris.org/jive/thread.jspa?threadID=48164&tstart=0 
> <https://opensolaris.org/jive/thread.jspa?threadID=48164&tstart=0>), so 
> this might be worthwhile (unless they are happy with the alternative way 
> of syncing up HG and SVN)
> 
> And of course there are the usual motivations (quoting from release notes):
> 1. In Subversion 1.4, the svndiff format has been improved to use much 
> less disk space — up to 50% less on plain text files in some cases. 
> Thus, if you choose to dump and reload your repository, the new 
> repository should be noticeably smaller on disk. Additionally, if a 
> client and server are both version 1.4 , then network traffic becomes 
> smaller and faster.
> 
> 2. The new working copy format allows the client to more quickly search 
> a working copy, detect file modifications, manage property metadata, and 
> deal with large files. The overall disk footprint is smaller as well, 
> with fewer inodes being used.
> 
> -Sandeep
> *
> *
> On Jan 4, 2008 12:42 AM, dormando <dormando at rydia.net 
> <mailto:dormando at rydia.net>> wrote:
> 
>     I'll find out how it was installed... Odds are we can't upgrade it too
>     easily. The code.sixapart.com <http://code.sixapart.com> machine
>     hosts a large number of projects
>     for various things. So we have to go through the whole formal
>     process of
>     verification, testing, backup and restore plans, blah blah.
> 
>     git-svn works fine for me though...
> 
>     -Dormando
> 
>     Sandeep Srinivasa wrote:
>      > Is upgrading the SVN version for the server going to be too much
>     of a
>      > problem?
>      >  From the Subversion release notes:
>      > http://subversion.tigris.org/svn_1.4_releasenotes.html
>      > < http://subversion.tigris.org/svn_1.4_releasenotes.html>
>      >
>      > Older clients and servers interoperate transparently with 1.4 servers
>      > and clients. Of course, some of the new 1.4 features may not be
>      > available unless both client and server are the latest version.
>     There is
>      > *no need* to dump and reload your repositories; Subversion 1.4
>     can read
>      > repositories created by earlier versions. To upgrade an existing
>      > installation, just install the newest libraries and binaries on
>     top of
>      > the older ones.
>      >
>      > Subversion 1.4 maintains API/ABI compatibility with earlier
>     releases, by
>      > only adding new functions. A program written to the 1.0, 1.1, 1.2
>     or 1.3
>      > API can both compile and run using 1.4 libraries. However, a program
>      > written for 1.4 cannot necessarily compile or run against older
>     libraries.
>      >
>      >
>      >       Looks safe enough.
>      >
>      >
>      >       thanks
>      >
>      > -Sandeep
>      >
>      >
>      >
>      >
>      >
>      > On Jan 3, 2008 11:49 PM, Steven Grimm < sgrimm at facebook.com
>     <mailto:sgrimm at facebook.com>
>      > <mailto:sgrimm at facebook.com <mailto:sgrimm at facebook.com>>> wrote:
>      >
>      >     git-svn talks to it just fine, so maybe one approach would be to
>      >     clone it with git, then use a git-hg converter (assuming such
>      >     exists; I know there's one to go the other direction.)
>      >
>      >     -Steve
>      >
>      >
>      >     On Jan 3, 2008, at 9:54 AM, Sandeep Srinivasa wrote:
>      >
>      >>     Hi,
>      >>         I have been following the discussion in this group for
>      >>     (atleast) creating a Mercurial/GIT repository.
>      >>
>      >>     Since, I was very interested in using a mercurial repo of
>      >>     memcached, I tried "hg convert" which uses standard Subversion
>      >>     Python bindings.
>      >>
>      >>     It failed with the various errors.
>      >>
>      >>     Subsequent attempts to use svnsync failed with an error that
>      >>     Dustin Sallings referred to here (
>      >>    
>     http://www.nabble.com/Re%3A-Developing-memcached%2C-how-should-we-do-it--p14321040.html
>     <http://www.nabble.com/Re%3A-Developing-memcached%2C-how-should-we-do-it--p14321040.html>)
>      >>
>      >>     The reason is similar to what is discussed here:
>      >>     http://forum.joomla.org/index.php?topic=157744.0;wap2
>     <http://forum.joomla.org/index.php?topic=157744.0;wap2>
>      >>     <http://forum.joomla.org/index.php?topic=157744.0;wap2> . It
>      >>     happens because people are attempting to use newer (> 1.4)
>     versions
>      >>     of Subversion to sync with memcached's 1.2.3 version, which does
>      >>     not support the "REPORT" command.
>      >>
>      >>     The problem is that the latest Mercurial releases need newer
>      >>     Subversion versions (> 1.4) to work nicely with the "hg convert"
>      >>     utilities.
>      >>
>      >>     If anybody has been able to indeed import the entire svn repo,
>      >>     please tell me how to. Alternatively, is it possible to upgrade
>      >>     memcached's Subversion version?
>      >>
>      >>     thanks
>      >>     Sandeep
>      >
>      >
> 
> 