[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Timeline for 1.6.0-final

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Tue, 10 Mar 2009 13:56:28 -0500

On Mar 10, 2009, at 1:52 PM, Mark Phippard wrote:

> On Tue, Mar 10, 2009 at 2:05 PM, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> We're getting close to 1.6.0-final. We've had very little word about
>> showstopper bugs in this release, and it looks like we're going to be
>> able to proceed with a release next month. Here's the current
>> timeline:
>> Mar. 16 @ 1200 UTC - Have finalized CHANGES file merged to trunk
>> Mar. 16 @ 1800 UTC - Roll 1.6.0-rc4, solicit signature collection
>> Mar. 17 (est.) - Publish 1.6.0-rc4 release
>> Mar. 18 @ 2200 UTC - Roll 1.6.0 final from same rev as 1.6.0-rc4
>> Mar. 20 @ 1500 UTC - Publish 1.6.0 release
>> Glancing over 1.6.x STATUS, there is one issue which concerns me a
>> little:
>> * ^/branches/1.6.x-UNC-paths
>> Resolves the regression on 1.6.X that disabled UNC path support on
>> Windows.
>> (All \\server\share format paths were canonicalized to /local/dir
>> format).
>> Justification:
>> A lot of Windows users use UNC paths in corporate environment.
>> While
>> not fully supported until issue #2028 and #2556 are resolved,
>> this is a
>> serious regression against older versions.
>> Notes:
>> Most of the changes in this branch are tests on the behavior of
>> path
>> functions. The real changes are in path.c and reroute unc
>> paths to
>> svn_dirent_*() functions.
>> The tests are there to make sure we don't regress again on the
>> 1.6.x
>> branch and to allow future merges in this part of the code.
>> Votes:
>> +1: rhuijben, gstein
>> This doesn't effect me directly, but it I can see how this could
>> impact a number of our users. If possible, I'd like to see this
>> reviewed so it can get into the final 1.6.0 tarball.
> If we can include this fix and keep to the proposed schedule, +1.
> Otherwise, I think it can wait to 1.6.1 which I understand we are
> planning for just a couple weeks later.
> I tested this problem and it at least fails in a "good way". Meaning
> SVN just does not see the path as a WC. It does not corrupt anything
> etc. A user can downgrade to 1.5.x, wait for 1.6.1 or map a drive to
> the path. Those all seem like reasonable workarounds.
> There was a lot of pent up demand for merge tracking and 1.5, and yet
> it seemed like months before users really started using it and asking
> merge questions. I do not see any reason to delay 1.6.0 for this bug
> when we can have a 1.6.1 release out shortly thereafter. AnkhSVN,
> TortoiseSVN etc. all provide their own builds so could patch in the
> fix if they are concerned about their users running into it.
> NOTE: I am not against including the fix in 1.6.0 in general. Only if
> it requires a re-soak.

Agreed on all points, and it's good to know that Subversion fails
gracefully in this case. I was just saying that if this change got
enough votes, I'd be happy to include it in the final tarball.


Received on 2009-03-10 19:57:10 CET

This is an archived mail posted to the Subversion Dev mailing list.