Re: [boost] Is our subversion server/archive 1.5 yet?

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-06-29 20:58:18

On Jun 29, 2008, at 4:39 PM, Douglas Gregor wrote:
> On Sun, 2008-06-29 at 16:12 -0400, Daryle Walker wrote:
>>
>>
[SNIP]
>
>> Is there a schedule for these upgrades to be done (if not done
>> already)?
[SNIP]
> As for the upgrade... we're looking into Subversion 1.5, but it  
> appears
> to be a nontrivial process to perform the upgrade and migrate
> svnmerge.py merge information appropriately, so we need to read  
> more, do
> some test runs, check that other projects haven't run into serious
> problems, etc. So much depends on the Subversion repository that we  
> need
> to be careful.
>
> When we're ready to move, we'll send out an e-mail to the mailing  
> list.

OK, I've quickly poked around some pages right now related to  
Subversion 1.5 and/or svnmerge.py (Googling "subversion 1.5  
svnmerge.py" w/o quotes), and here's my suggestions on the policy we  
should take here.  Since I'm guesstimating, please double check with  
actual Subversion experts before enacting this.

A key assumption I made is that, although the SVN-1.5 merge system is  
loosely based on svnmerge, they use distinct name-spaces for the meta- 
data attributes needed.

1.  We can upgrade the server system to 1.5 right away.  Since the  
repository won't be converted (yet), the server will act in 1.4- 
compatibility mode and 1.4-clients (and 1.5-clients, mostly) will be  
none the wiser.  Enjoy the bug fixes, but maybe anti-enjoy the  
bleeding edge.  Look & see, and possibly wait for 1.5.1.

2.  After the new server works to our satisfaction, we can apply the  
upgrade procedure to our repository.  Members with 1.5-clients can  
fully use the new features, but 1.4-clients will still be none the  
wiser.

3.  [I am _assuming_ here.]  The 1.4/svnmerge and native-1.5 systems  
use distinct meta-attributes, and therefore CAN CO-EXIST on the same  
server.  Anyone can checkout and use branches created by either  
system; but the branching, merging from trunk, and final merging to  
trunk phases MUST all be done by members with the same branch/merge  
philosophy!  In other words, a 1.4/svnmerge member can checkout a  
branch created by a native-1.5 member, but only other native-1.5  
members should handle any (re)merging, and vice-versa.  Members with  
1.5-clients must get a copy of the svnmerge script to keep using a  
branch under the 1.4/svnmerge system.  (I don't know if the script is  
still included.)

4.  I feel that automatic migration between branch/merge systems,  
with the provided script, SHOULD NOT be done.  Migration assumes a  
one-way path; once the server does the migration, all members MUST  
dump svnmerge and switch to 1.5 clients if they want to keep merge  
control on branches (since the svnmerge meta-data is purged/ 
outdated)!  This is easy for a single developer or a dictatorial  
programming group, but not good for a rag-tag band of programmers  
that come in and out of play at different rates.

5.  Once we transition fully to 1.5, members should branch/merge with  
the native-1.5 system for NEW branches.  Members with 1.4-clients  
need to upgrade to a 1.5-client to have merge control[1].  Existing  
branches should retain the 1.4/svnmerge system (so 1.5-clients need  
to download the script), but should wrap up their lifetimes as soon  
as possible to reduce the mix of branch/merge systems.  (I don't  
think members should kill a 1.4/svnmerge system and immediately  
resurrect it as native-1.5.)

[1] Note that using a 1.5-client on a pre-1.5 working copy  
automatically upgrades said working copy.  That working copy is now  
unusable by any GUI client, Explorer/Finder plug-in, or other client  
that carries an internal copy of the 1.4 APIs (or official command- 
line client).

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com