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