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