wiki:TCTSvnUpgradeVote
Last modified 9 years ago Last modified on 08/03/2010 01:38:29 PM

Upgrade to SVN 1.6.9

Proposal

Robyn Allsman; Tue Jun 29 13:21:11 MST 2010

Hello TCT members,

Discussion and a vote is requested. Background information is below.

TCT Voting

TCT Members, please discuss the issue and/or submit your vote on:

yes: immediately require any user not using a 1.6.9+ SVN client to move their
     development work over to the lsst cluster until they upgrade their 
     personal SVN client.
     The PT1/PT2 split will occur as soon as the SVN server upgrade occurs.

no: it's too rushed.  Delay bifurcation of PT1/PT2 software until SVN server
    and clients are upgraded to svn 1.6.9+ .

no: it's too rushed. Delay upgrading SVN server, thus requiring all SVN clients 
    to upgrade, also.  But go ahead with the PT1/PT2 branching and hope that
    we aren't hit by the merge bug.

Feel free to propose alternative voting options.

Your vote is important, please use it wisely. And do it before Thrusday.

Background Information

At today's DC3b meeting today, we discussed the method and timing of the tagging of the PT1 software suite. K-T reported that the latest changes targetted to fix the WCS seem to have been successful. K-T is preparing tagged versions of all modules reflecting a PT1 consistent stack. With a PT1 tagged suite, it was felt that the trunks should be split into a PT1 bug-fix branch and a PT2 mainline trunk.

With the imminent split into two working branches, the merge enhancement of SVN 1.6.9 was felt to be extremely important.

In the April 14, 2010 TCT meeting http://dev.lsstcorp.org/trac/wiki/CcbMeeting20100414

  • The TCT agreed to the [svn V1.6.9+] upgrade but wanted the upgrade not to affect PT1 development.
  • Post meeting, Robyn sent email to the developers notifying them to upgrade their local system's SVN release to SVN 1.6.9 at their convenience but sometime after PT1, a firm date would be provided.

Since PT1 development has transitioned to bug fixes rather than development, constraint 1 was considered satisfied by the participants of the DC3 meeting.

Although the users were notified in April that they should upgrade their SVN clients, there was no requirement that it occur so we do not know who might not have updated their local SVN clients. It was discussed that those who have not already converted could transition their use to the lsst cluster (upgraded many months ago) until they perform their local SVN client upgrade.

K-T is strongly requesting that the TCT approve the upgrade of SVN to V 1.6.9+ immediately so that the branch split is supported by SVN clients which handle merge operations correctly.

Due to K-T's vacation schedule, he would like resolution on this issue of permitting an immediate upgrade to SVN clients 1.6.9+ prior to this Thursday.

Discussion

Ray Plante; Tue Jun 29 13:35:25 MST 2010

On Tue, 29 Jun 2010, Robyn Allsman wrote:

With the imminent split into two working branches, the merge enhancement of SVN 1.6.9 was felt to be extremely important.

Unfortunately, I missed the phone call. Can someone summarize why this is considered "extremely important" to the split? I believe this has something to do with issues of merging, but I would appreciate a knowledgable statement of specifically what problems this will solve or avoid.

Kian-Tat Lim; Tue Jun 29 14:01:49 MST 2010

TCT members,

Can someone summarize why this is considered "extremely important" to the split?

I believe the SVN server has already been upgraded to version 1.6. Many users have already upgraded their clients to 1.6. The last thing that needs to happen is for the repository to be upgraded to 1.6 as well, forcing clients to upgrade.

The primary improvements that the svn 1.6 line brings are detection of tree conflicts (resulting from file renames, moves, and

removals): http://subversion.apache.org/docs/release-notes/1.6.html#tree-conflicts and fixes to svn merge including --reintegrate.

Since we're expecting many files to move or be renamed as code is refactored in PT2, having the ability to track these properly is highly desirable.

Note this quote from the SVN book:

When this situation arises, there is the possibility that the user makes a commit without realizing that local modifications have been left in a now-unversioned file in the working copy, and have not reached the repository.

Russell Owen; Tue Jun 29 14:03:23 MST 2010

I'll take a stab at this.

The merge info kept by svn 1.5 is not adequate to reliably merge tickets and branches back to the trunk. There are often serious conflicts caused by svn's keeping insufficient metadata around. A common symptom is that renaming a file can result in conflicts that are obscure and hard to clean up.

svn 1.6 greatly improved the situation (though it is still not perfect).

We will not gain the benefits of 1.6 until we put the svn repository into 1.6 format and require users to use svn client 1.6. Meanwhile branching is risky.

Gregory P. Dubois-Felsmann; Tue Jun 29 13:43:48 MST 2010

Could we be reminded of whether the repository also must be upgraded to the 1.6 format before the "merge enhancement" becomes available? It doesn't look like we explicitly documented this last time.

Robert Lupton; Tue Jun 29 13:54:53 MST 2010

The repo does need to be upgraded to get the new merge support (but I don't see the reference off hand)

As to whether it's needed, I think the answer's, "Yes"; see http://subversion.apache.org/docs/release-notes/1.6.html#tree-conflicts:

Subversion 1.6 recognizes a new kind of conflict, known as a "tree conflict". Such conflicts manifest at the level of directory structure, rather than file content.

Situations now flagged as conflicts include deletions of locally modified files, and incoming edits to locally deleted files. Files and directories which are victims of a tree conflict cannot be committed before the conflict is marked resolved.

Note that Subversion is still treating renames as a "copy+delete" operation, so file renames causing tree conflicts can only be detected in terms of file additions and deletions. Because of this, false positives during tree conflict detection are possible.

To facilitate tree conflict detection, attempting to commit the deletion of a file which has already been deleted in the HEAD revision now causes an error. In Subversion 1.5, this was treated as a no-op, potentially resulting in "empty" revisions which contained no changes.

Kian-Tat Lim; Tue Jun 29 13:53:41 MST 2010

TCT members,

And do it before Thursday.

[...]

Due to K-T's vacation schedule, he would like resolution on this issue of permitting an immediate upgrade to SVN clients 1.6.9+ prior to this Thursday.

This is not just because of my vacation schedule. This is also because July 1 is a good day to get production going, as it will mean we are "only" two months late and have a shot at keeping the DC3a-to-DC3bPT1 interval below one full year.

Vote

Tim Axelrod; Tue Jun 29 15:00:48 MST 2010

Hi All,

I've read the discussion, and the value of requiring the client upgrade seems clear. I vote "yes".

Robert Lupton; Tue Jun 29 15:01:43 MST 2010

Ah, I didn't vote. Yes, please.

Robyn Allsman; Tue Jun 29 15:31:49 MST 2010

Hello TCT,

And my sentiments were somewhat obvious from the vote options.

I vote to immediately upgrade the repository then cut the branch. Developers will need to migrate their work to the lsst cluster until they upgrade thei svn client.

This gives us 4 out of 6 TCT members voting yes. Hopefully Gregory and Schuyler don't have reservations they haven't shared.

The vote passes.

David, Please carry forward with the repository upgrade at your earliest convenience.

The PT1/PT2 split will occur after the repository upgrade.

Gregory P. Dubois-Felsmann; Wed Jun 30 16:32:58 MST 2010

On Tue, 29 Jun 2010, Robyn Allsman wrote:

This gives us 4 out of 6 TCT members voting yes. Hopefully Gregory and Schuyler don't have reservations they haven't shared.

For the record, I had none; just wasn't able to get back online before Robyn got her quorum.

Schuyler D. Van Dyk; 01 Jul 2010 16:28:22.0956 (UTC)

(From Europe.)

I'll go along with the majority on this.