Re: [boost] Is our subversion server/archive 1.5 yet?
On Sun, 2008-06-29 at 16:12 -0400, Daryle Walker wrote:
Last week, a was bouncing around sites and found out that Subversion 1.5.0 has gone final. I've downloaded it because I want to try its built-in merging support (to fix up Boost.Integer in a branch). Has our subversion system been updated to 1.5?
No, we're still using Subversion 1.4 on the server.
Obviously, if the client and server use subversion versions 1.x and 1.y respectively, the transactions will proceed as the lower of those versions. Therefore, both individual clients and the server must be at least the 1.5 level to use built-in merging. There's another requirement, though: if the server is upgraded to 1.5, the repositories it manages aren't automatically upgraded. If a repository isn't upgraded to the 1.5 format, then the server will act in 1.4-compatibility mode as needed.
Is there a schedule for these upgrades to be done (if not done already)? Is it possible to tell from the client side which mode a server/repository uses?
I actually don't know how to tell from the client-side which version of Subversion the server is running. 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. - Doug
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
Daryle Walker wrote:
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.)
Once we fully transition to 1.5, we can use svnmerge-migrate-history.py to convert svnmerge.py's history to the 1.5 merge history format: http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/svnmerge-... David
On Jun 30, 2008, at 12:33 PM, David Walthall wrote:
Daryle Walker wrote:
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.)
Once we fully transition to 1.5, we can use svnmerge-migrate- history.py to convert svnmerge.py's history to the 1.5 merge history format: http://svn.collab.net/repos/svn/trunk/contrib/client-side/svnmerge/ svnmerge-migrate-history.py
I talked about this in point #4. I warned that the script is one- way; that every Boost member that uses merge control _must_ switch to the 1.5 APIs after the repository is converted away from svnmerge. I don't know how strict we can be on that, so I suggested to make new merging branches in the 1.5 format, but keep any outstanding 1.4/ svnmerge branches as-is. (And any older-style merging branches should be wrapped up as soon as possible.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
On Jun 29, 2008, at 8:58 PM, Daryle Walker wrote:
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.
We still want to make sure that
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.
Assuming there are no showstopper bugs with Subversion 1.5. It is a major upgrade, so we do need to be careful here.
[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).
The good news is that TortoiseSVN 1.5.0 has also been released, so there isn't much of an excuse to have a pre-1.5 client (unless something is very broken). - Doug
Doug Gregor wrote:
On Jun 29, 2008, at 8:58 PM, Daryle Walker wrote:
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.
We still want to make sure that
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.
Assuming there are no showstopper bugs with Subversion 1.5. It is a major upgrade, so we do need to be careful here.
I think we should wait at least a month and possibly longer to make sure 1.5 is stable. Also, I'd much rather change to 1.5 early in one of our quarterly release cycles rather than late in a cycle. Thanks, --Beman
On Jun 30, 2008, at 1:08 PM, Doug Gregor wrote:
On Jun 29, 2008, at 8:58 PM, Daryle Walker wrote:
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.
We still want to make sure that
[SNIP]
Was there more to that sentence, but got cut off?...
[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).
The good news is that TortoiseSVN 1.5.0 has also been released, so there isn't much of an excuse to have a pre-1.5 client (unless something is very broken).
Not every platform has TortoiseSVN. (And the Mac equivalent hasn't been updated yet. I downloaded the 1.5 Mac distribution, which includes a CLI client, but not used it.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
On Jul 2, 2008, at 12:05 AM, Daryle Walker wrote:
Not every platform has TortoiseSVN. (And the Mac equivalent hasn't been updated yet. I downloaded the 1.5 Mac distribution, which includes a CLI client, but not used it.)
Well, the SCPlugin just got updated a few days ago, and it comes in Subversion 1.4.6 and 1.5.0 variants. I downloaded the latter. (And changed all my other Subversion tools to 1.5.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
2008/7/18 Daryle Walker <darylew@hotmail.com>:
On Jul 2, 2008, at 12:05 AM, Daryle Walker wrote:
Not every platform has TortoiseSVN. (And the Mac equivalent hasn't been updated yet. I downloaded the 1.5 Mac distribution, which includes a CLI client, but not used it.)
Well, the SCPlugin just got updated a few days ago, and it comes in Subversion 1.4.6 and 1.5.0 variants. I downloaded the latter. (And changed all my other Subversion tools to 1.5.)
Subversion 1.5 won't be in a stable Ubuntu release until October. I don't know about other linux distributions. Daniel
participants (6)
-
Beman Dawes -
Daniel James -
Daryle Walker -
David Walthall -
Doug Gregor -
Douglas Gregor