You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2005/04/26 19:11:20 UTC
svn 1.2 resoak?
So... now that svn 1.2.0-rc2 is released, there really hasn't been any
formal discussion on this list about resetting the 1.2 "soak" time --
just some informal irc chatter.
Looking at the differences between rc1 and rc2, there were couple of
really big bugs fixed (the svn:needs-lock bug on win32, and the FSFS
race condition), and a bunch of small-to-medium-sized bugs (some crash
fixes, some various behavior fixes, some reversions of new behaviors
too).
In general, I get the feeling that we *ought* to restart the 4 week
soak from yesterday. The gut says we should give users that much time
to re-test things. But to be perfectly upfront about motivations,
Collabnet is under a really tight deadline to integrate svn 1.2 into
its next release, and we're hoping that folks might agree to a 3-week
soak instead. We don't want to compromise the quality of svn 1.2, but
we also don't want to miss the CEE release. :-)
The question I'm placing on the table is: is there some sort of extra
testing we can do so that our collective conscience doesn't feel
guilty about a 3-week resoak? I know that the Collabnet employees
have some extra bandwidth we can spend in testing, if we can get some
consensus on exactly what/how we should be testing.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, April 26, 2005 3:19 PM -0400 Greg Hudson <gh...@MIT.EDU>
wrote:
> My personal feeling is that we don't need a resoak, but I don't feel
> strongly about the matter.
Agreed. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Greg Hudson <gh...@MIT.EDU>.
My personal feeling is that we don't need a resoak, but I don't feel
strongly about the matter.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by "C. Michael Pilato" <cm...@collab.net>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Philip Martin <ph...@codematters.co.uk> writes:
>
> > Ben Collins-Sussman <su...@collab.net> writes:
> >
> > > The question I'm placing on the table is: is there some sort of extra
> > > testing we can do so that our collective conscience doesn't feel
> > > guilty about a 3-week resoak? I know that the Collabnet employees
> > > have some extra bandwidth we can spend in testing, if we can get some
> > > consensus on exactly what/how we should be testing.
> >
> > Some testing ideas:
> >
> > 1. Get 1.2.0-rc2 installed on svn.collab.net.
>
> I'll have that done tomorrow -- possibly tonight.
Ah, I couldn't wait -- it's done now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Philip Martin <ph...@codematters.co.uk> writes:
> Ben Collins-Sussman <su...@collab.net> writes:
>
> > The question I'm placing on the table is: is there some sort of extra
> > testing we can do so that our collective conscience doesn't feel
> > guilty about a 3-week resoak? I know that the Collabnet employees
> > have some extra bandwidth we can spend in testing, if we can get some
> > consensus on exactly what/how we should be testing.
>
> Some testing ideas:
>
> 1. Get 1.2.0-rc2 installed on svn.collab.net.
I'll have that done tomorrow -- possibly tonight.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Philip Martin <ph...@codematters.co.uk>.
Philip Martin <ph...@codematters.co.uk> writes:
> 2. Run the 1.2.x regression tests with pool debugging under valgrind
> (I would expect export failures if --enable-dso is used).
Oops, just checked my TODO stack: it's import that's dodgy, so that
might make the pool debugging/valgrind/--enable-dso combination a
non-starter.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2005-05-04 12:47-0500, Ben Collins-Sussman wrote:
>
> On Apr 26, 2005, at 4:47 PM, Philip Martin wrote:
> >
> >3. Test network compatibility: run the 1.2 regression tests against
> > 1.1 and 1.0 mod_dav_svn and svnserve. Run the 1.1 and 1.0
> > regression tests against 1.2 mod_dav_svn and svnserve.
> >
>
> I really, really want to do this. But I'm having trouble thinking of a
> clever way to do it.
>
> The problem is that 'make check BASE_URL=blah' can't be running on some
> faraway machine; it requires local access to the test-area's
> repositories.
>
> Any ideas?
How about this kind of setup:
Testing 1.2.x client against 1.1.x server:
1) Install 1.1.x to /inst/path/1.1.x-rXXXXX
1.1) Install mod_dav_svn from 1.1.x
2) build 1.2.x
2.1) Edit by hand that 1.2.x test fw will use svnadmin and svnlook
from 1.1.x installation
subversion/tests/clients/cmdline/svntest/main.py:97
svnadmin_binary = ...
svnlook_binary = ...
svnversion_binary = ...
3) run tests
And same for running 1.1.x client against 1.2.x server. I would try
this at some point with my svntest installation.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Ben Collins-Sussman <su...@collab.net>.
On Apr 26, 2005, at 4:47 PM, Philip Martin wrote:
>
> 3. Test network compatibility: run the 1.2 regression tests against
> 1.1 and 1.0 mod_dav_svn and svnserve. Run the 1.1 and 1.0
> regression tests against 1.2 mod_dav_svn and svnserve.
>
I really, really want to do this. But I'm having trouble thinking of a
clever way to do it.
The problem is that 'make check BASE_URL=blah' can't be running on some
faraway machine; it requires local access to the test-area's
repositories.
Any ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Philip Martin <ph...@codematters.co.uk>.
Ben Collins-Sussman <su...@collab.net> writes:
> The question I'm placing on the table is: is there some sort of extra
> testing we can do so that our collective conscience doesn't feel
> guilty about a 3-week resoak? I know that the Collabnet employees
> have some extra bandwidth we can spend in testing, if we can get some
> consensus on exactly what/how we should be testing.
Some testing ideas:
1. Get 1.2.0-rc2 installed on svn.collab.net.
2. Run the 1.2.x regression tests with pool debugging under valgrind
(I would expect export failures if --enable-dso is used).
3. Test network compatibility: run the 1.2 regression tests against
1.1 and 1.0 mod_dav_svn and svnserve. Run the 1.1 and 1.0
regression tests against 1.2 mod_dav_svn and svnserve.
4. Test library compatibility: build 1.1.x, then arrange for the 1.1.x
binaries to use the 1.2.x libraries, then run the 1.1.x regression
tests.
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
Michael Sweet <mi...@easysw.com> writes:
> Perhaps you could update the policy to advocate posting "me, too!"
> messages to existing bug reports, so that you know how many people
> have that particular issue?
Actually, I'd rather not. Traffic is already high enough on these
lists :-). One bug report is really all we need.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
Michael Sweet <mi...@easysw.com> writes:
> Agreed, I was advocating adding the "me, too!" messages to the
> issue text, not on the dev list... :) Otherwise, how can you go
> back and see how "popular" the issue is/was???
Yeah, Brian Behlendorf pointed out to me (privately) that that was
what you meant, I just misread your post, sorry. No problem with
annotating existing issues. I just wanted to keep mailing list noise
down, that's all.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Michael Sweet <mi...@easysw.com>.
Brian W. Fitzpatrick wrote:
>
> On Apr 29, 2005, at 9:48 AM, Michael Sweet wrote:
>
>> kfogel@collab.net wrote:
>>
>>> Luis Muniz <lu...@b2boost.com> writes:
>>>
>>>> Yes, well people are not exactly encouraged to report a bug
>>>> twice... everywhere the policy says to read first the archive.
>>>
>>> That's a good point. If people are following that policy (even some
>>> of the time), then I shouldn't make assumptions about how many other
>>> people have encountered a bug, once someone has reported it.
>>
>>
>> Perhaps you could update the policy to advocate posting "me, too!"
>> messages to existing bug reports, so that you know how many people
>> have that particular issue?
>
>
> I'd be fine with this sort of thing taking place within an existing
> issue (e.g. "I'm also experiencing this bug with svn 1.1.3 on FC3 while
> using my laptop on a wireless connection under large trees"), but I'd
> rather not spam the dev list with it.
Agreed, I was advocating adding the "me, too!" messages to the
issue text, not on the dev list... :) Otherwise, how can you go
back and see how "popular" the issue is/was???
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by "Brian W. Fitzpatrick" <fi...@red-bean.com>.
On Apr 29, 2005, at 9:48 AM, Michael Sweet wrote:
> kfogel@collab.net wrote:
>> Luis Muniz <lu...@b2boost.com> writes:
>>> Yes, well people are not exactly encouraged to report a bug
>>> twice... everywhere the policy says to read first the archive.
>> That's a good point. If people are following that policy (even some
>> of the time), then I shouldn't make assumptions about how many other
>> people have encountered a bug, once someone has reported it.
>
> Perhaps you could update the policy to advocate posting "me, too!"
> messages to existing bug reports, so that you know how many people
> have that particular issue?
I'd be fine with this sort of thing taking place within an existing
issue (e.g. "I'm also experiencing this bug with svn 1.1.3 on FC3 while
using my laptop on a wireless connection under large trees"), but I'd
rather not spam the dev list with it.
-Fitz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Michael Sweet <mi...@easysw.com>.
kfogel@collab.net wrote:
> Luis Muniz <lu...@b2boost.com> writes:
>
>>Yes, well people are not exactly encouraged to report a bug
>>twice... everywhere the policy says to read first the archive.
>
>
> That's a good point. If people are following that policy (even some
> of the time), then I shouldn't make assumptions about how many other
> people have encountered a bug, once someone has reported it.
Perhaps you could update the policy to advocate posting "me, too!"
messages to existing bug reports, so that you know how many people
have that particular issue?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
Luis Muniz <lu...@b2boost.com> writes:
> Yes, well people are not exactly encouraged to report a bug
> twice... everywhere the policy says to read first the archive.
That's a good point. If people are following that policy (even some
of the time), then I shouldn't make assumptions about how many other
people have encountered a bug, once someone has reported it.
> I can testify that I have found this bug in 30min after installing
> SVN, because it's the first feature I wanted to test,
> -locking with a user
> -modifying
> -committing
>
> -updating with another user
>
> It seems like a really common use pattern. I'm not a specialist, I
> don't even know the other bugfixes that were submitted. But if your
> fears are based on this case, I think you are overreacting
Well, they're based on more than this one case -- there's still been a
fair amount of code churn. But yes, what you say does alleviate my
concerns about that particular bug quite a bit.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Luis Muniz <lu...@b2boost.com>.
kfogel@collab.net wrote:
>
>These circumstances were not a complete edge case, but they wouldn't
>come up in most people's daily use of Subversion either. Thus,
>although we might expect that such a bug on Windows would be caught by
>lots and lots of people, IIRC only one user noticed it (or anyway, one
>user reported it).
>
Yes, well people are not exactly encouraged to report a bug twice...
everywhere the policy says to read first the archive.
I can testify that I have found this bug in 30min after installing SVN,
because it's the first feature I wanted to test,
-locking with a user
-modifying
-committing
-updating with another user
It seems like a really common use pattern. I'm not a specialist, I don't
even know the other bugfixes that were submitted. But if your fears are
based on this case, I think you are overreacting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Julian Foad <ju...@btopenworld.com>.
kfogel@collab.net wrote:
[about how long a soak period is appropriate for 1.2.0]
> Thoughts?
As usual, you talk a great deal of sense. I find nothing to quibble with.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
kfogel@collab.net writes:
> I'm not -1'ing the 3-week proposal. Yet. I've started reviewing all
> the merges onto the 1.2.x line between RC1 and RC2. I'd rather base
> such a decision on a close examination of the changes in question,
> than on vague, fuzzy feelings about code churn. If in the end I'm
> still jittery about a shortened soak, and want to propose a full soak,
> I'll at least have details to back it up. (One thing I wish we had
> stats for is, how many -- and what sort of -- bugs were found in 1.1.0
> during its final week of soak.) In the meantime, the clock is still
> ticking, so we're not losing any ground.
Okay, I've looked over every merge between rc1 and rc2, and the churn
wasn't nearly as bad as I thought. I've also looked at the merges
from rc2 to present, and nothing there looks very dangerous either.
So +1 on the 3-week soak, and a 1-week soak for the final tarball.
That means we should try to roll that final tarball (rc3) soon, like,
Monday? :-) I'll post a separate mail about that.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Michael Sweet <mi...@easysw.com>.
kfogel@collab.net wrote:
> ...
> My feeling is, if we're comfortable with a 3 week soak for RC2 --
> given additional testing -- then we ought to consider a more general
> policy change. Such as:
>
> The total soak time of all release candidates in a minor line must
> be at least 4 weeks. The last release candidate must have soaked
> for at least 2 weeks before being promoted to a final release.
>
> Thoughts?
This is pretty much what we have been doing for all of our projects
for a few years now; minimum 2 weeks between RC and final, and no
final release until all high priority bugs are resolved. Most (new)
bugs seem to come in the first week...
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
kfogel@collab.net writes:
> I'm not -1'ing the 3-week proposal. Yet. I've started reviewing all
> the merges onto the 1.2.x line between RC1 and RC2. I'd rather base
> such a decision on a close examination of the changes in question,
> than on vague, fuzzy feelings about code churn. If in the end I'm
> still jittery about a shortened soak, and want to propose a full soak,
> I'll at least have details to back it up. (One thing I wish we had
> stats for is, how many -- and what sort of -- bugs were found in 1.1.0
> during its final week of soak.) In the meantime, the clock is still
> ticking, so we're not losing any ground.
By the way, if anyone wants to do what I'm doing, here's a complete
list of the 25 core code changes between RC1 and RC2. Some of these
are quite trivial, others are not.
------------------------------------------------------------------------
r14392 | dlr | 2005-04-21 18:17:12 -0500 (Thu, 21 Apr 2005) | 6 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_ra_svn/client.c
Merge r14373 from trunk into the 1.2 branch to pass all of URI
hostinfo to ra_svn tunnel agent to include the port number.
Approved by:
+1: ghudson, breser, dlr
------------------------------------------------------------------------
r14388 | dlr | 2005-04-21 18:00:39 -0500 (Thu, 21 Apr 2005) | 6 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/mod_dav_svn/liveprops.c
M /branches/1.2.x/subversion/mod_dav_svn/repos.c
Merge r14262, r14359, and r14365 from trunk into the 1.2 branch to fix
SVN issue #2049, making auto-versioning cooperate with mod_mime.
Approved by:
+1: fitz, sussman, dlr
------------------------------------------------------------------------
r14384 | breser | 2005-04-21 17:27:36 -0500 (Thu, 21 Apr 2005) | 8 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_ra_dav/fetch.c
M /branches/1.2.x/subversion/mod_dav_svn/file_revs.c
M /branches/1.2.x/subversion/mod_dav_svn/log.c
M /branches/1.2.x/subversion/mod_dav_svn/update.c
M /branches/1.2.x/subversion/mod_dav_svn/version.c
M /branches/1.2.x/subversion/tests/clients/cmdline/update_tests.py
Merge r14041, r14149, r14186, r14194, r14238, r14273 onto 1.2.x
Fix issue #2268 (svn update of xml-unsafe dir (from within) http error)
and similar problems regarding paths with leading or trailing spaces.
Votes: +1: lundblad, cmpilato, fitz
------------------------------------------------------------------------
r14375 | lundblad | 2005-04-21 15:05:28 -0500 (Thu, 21 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_fs_fs/fs_fs.c
Merge r14333 from trunk to 1.2.x branch.
Fix remotely (meaning ra_dav/ra_svn) triggerable crash in fsfs.
Approved by:
+1: ringstrom, sussman, lundblad
------------------------------------------------------------------------
r14357 | breser | 2005-04-21 13:10:28 -0500 (Thu, 21 Apr 2005) | 8 lines
Changed paths:
M /branches/1.2.x/subversion/libsvn_fs_fs/fs_fs.c
M /branches/1.2.x/subversion/libsvn_fs_fs/lock.c
M /branches/1.2.x/subversion/libsvn_fs_fs/lock.h
M /branches/1.2.x/subversion/libsvn_fs_fs/tree.c
M /branches/1.2.x/subversion/tests/libsvn_fs/locks-test.c
Merge r14259 onto 1.2.x
Fix #2262, including making lock expiration work in FSFS on recursive
operations.
Votes: +1: lundblad, fitz, sussman
------------------------------------------------------------------------
r14356 | breser | 2005-04-21 13:09:22 -0500 (Thu, 21 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_subr/io.c
M /branches/1.2.x/subversion/tests/clients/cmdline/lock_tests.py
Merge r14304, 14306 onto 1.2.x
Fix issue #2278: svn:needs-lock property interferes with update on Windows
Votes: +1: brane, lundblad, sussman; +0: kfogel
------------------------------------------------------------------------
r14332 | lundblad | 2005-04-20 14:58:37 -0500 (Wed, 20 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_ra_dav/session.c
Merge r14295 from trunk to 1.2.x branch.
Fix memory problem with neon lock hook.
Approved by:
+1: philip, brane, lundblad
------------------------------------------------------------------------
r14331 | lundblad | 2005-04-20 14:55:44 -0500 (Wed, 20 Apr 2005) | 8 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_repos/repos.c
Merge r14324 from trunk to 1.2.x branch.
Fix post-(un)lock hook templates to use mailer.py and stop messing
with STDIN.
Approved by:
+1: fitz, cmpilato, lundblad
------------------------------------------------------------------------
r14317 | dlr | 2005-04-19 16:12:53 -0500 (Tue, 19 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/build.conf
M /branches/1.2.x/subversion/libsvn_client/commit.c
M /branches/1.2.x/subversion/tests/clients/cmdline/basic_tests.py
A /branches/1.2.x/subversion/tests/clients/cmdline/import_tests.py (from /trunk/subversion/tests/clients/cmdline/import_tests.py:14293)
Merge r14293 from trunk to 1.2.x branch.
Make 'svn import' not create empty revisions.
Approved by:
+1: cmpilato, brane, lundblad
------------------------------------------------------------------------
r14299 | lundblad | 2005-04-18 14:04:06 -0500 (Mon, 18 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/clients/cmdline/help-cmd.c
M /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn--version_stdout
Merge r14223 from trunk to 1.2.x branch.
Drop listing of FS modules from "svn --version" output.
Approved by:
+1: lundblad, fitz, philip
------------------------------------------------------------------------
r14255 | lundblad | 2005-04-16 15:23:41 -0500 (Sat, 16 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/include/svn_fs.h
M /branches/1.2.x/subversion/libsvn_fs/fs-loader.c
M /branches/1.2.x/subversion/libsvn_fs/fs-loader.h
M /branches/1.2.x/subversion/libsvn_fs_base/fs.c
M /branches/1.2.x/subversion/libsvn_fs_fs/fs.c
M /branches/1.2.x/subversion/libsvn_fs_fs/fs.h
M /branches/1.2.x/subversion/libsvn_fs_fs/fs_fs.c
M /branches/1.2.x/subversion/mod_dav_svn/mod_dav_svn.c
M /branches/1.2.x/subversion/svnserve/main.c
Merge 1.2.x-r14063 branch to 1.2.x branch.
Fix FSFS locking problem.
Approved by:
+1: ghudson, lundblad, fitz
------------------------------------------------------------------------
r14254 | lundblad | 2005-04-16 15:17:47 -0500 (Sat, 16 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/include/svn_ra.h
M /branches/1.2.x/subversion/libsvn_ra_dav/session.c
M /branches/1.2.x/subversion/libsvn_ra_local/ra_plugin.c
M /branches/1.2.x/subversion/libsvn_ra_svn/client.c
Merge r14241 from trunk to 1.2.x branch.
svn_ra_lock_callback API docs and caller fix.
Approved by:
+1: lundblad, dlr, fitz
------------------------------------------------------------------------
r14213 | lundblad | 2005-04-14 13:17:04 -0500 (Thu, 14 Apr 2005) | 8 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/include/svn_fs.h
M /branches/1.2.x/subversion/include/svn_repos.h
M /branches/1.2.x/subversion/libsvn_fs/fs-loader.c
M /branches/1.2.x/subversion/libsvn_fs/fs-loader.h
M /branches/1.2.x/subversion/libsvn_fs_base/lock.c
M /branches/1.2.x/subversion/libsvn_fs_base/lock.h
M /branches/1.2.x/subversion/libsvn_fs_fs/lock.c
M /branches/1.2.x/subversion/libsvn_fs_fs/lock.h
M /branches/1.2.x/subversion/libsvn_ra_local/ra_plugin.c
M /branches/1.2.x/subversion/libsvn_repos/fs-wrap.c
M /branches/1.2.x/subversion/mod_dav_svn/lock.c
M /branches/1.2.x/subversion/tests/libsvn_fs/locks-test.c
Merge r14180 from trunk to 1.2.x branch.
Make the public locking API semantics for lock expiry match the internal
storage and known concerned caller's semantics.
Approved by:
+1: cmpilato, lundblad, dlr
------------------------------------------------------------------------
r14197 | lundblad | 2005-04-14 04:02:46 -0500 (Thu, 14 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/include/svn_test.h
Merge r14118, r14137 from trunk to 1.2.x branch.
De-doxygenate svn_test.h.
Approved by:
+1: maxb, ghudson, cmpilato, lundblad
------------------------------------------------------------------------
r14196 | lundblad | 2005-04-14 03:56:37 -0500 (Thu, 14 Apr 2005) | 6 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/build.conf
M /branches/1.2.x/subversion/libsvn_client/cat.c
A /branches/1.2.x/subversion/tests/clients/cmdline/cat_tests.py (from /trunk/subversion/tests/clients/cmdline/cat_tests.py:14098)
Merge r14081, r14098 from trunk to 1.2.x branch.
Fix Issue 1361: 'svn cat file -r BASE' contacts repository
Approved by:
+1: jszakmeister, dionisos, cmpilato
------------------------------------------------------------------------
r14192 | lundblad | 2005-04-14 02:52:05 -0500 (Thu, 14 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_ra_svn/client.c
M /branches/1.2.x/subversion/tests/clients/cmdline/lock_tests.py
Merge r14169 from trunk to 1.2.x branch.
Make locking an out-of-date file fail over ra_svn.
Approved by:
+1: lundblad, jszakmeister, cmpilato
------------------------------------------------------------------------
r14191 | lundblad | 2005-04-14 02:49:00 -0500 (Thu, 14 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_fs_fs/fs_fs.c
Merge r14131 from trunk to 1.2.x branch.
In FSFS, don't auto-upgrade FS format number of legacy repositories.
Approved by:
+1: kfogel, ghudson, jszakmeister
------------------------------------------------------------------------
r14190 | lundblad | 2005-04-14 02:45:56 -0500 (Thu, 14 Apr 2005) | 8 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/clients/cmdline/lock-cmd.c
M /branches/1.2.x/subversion/clients/cmdline/main.c
Merge r14126 from trunk to 1.2.x branch.
Tweaks to the lock comment handling, including getting rid of the
editor invocation.
Approved by:
+1: lundblad, kfogel, ghudson
------------------------------------------------------------------------
r14109 | maxb | 2005-04-11 08:03:20 -0500 (Mon, 11 Apr 2005) | 6 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_wc/adm_crawler.c
M /branches/1.2.x/subversion/libsvn_wc/adm_ops.c
M /branches/1.2.x/subversion/libsvn_wc/copy.c
Merge r14097 from trunk to 1.2.x branch.
Fix further GCCisms.
Approved by: +1: maxb, lundblad, ringstrom
------------------------------------------------------------------------
r14103 | lundblad | 2005-04-11 06:51:31 -0500 (Mon, 11 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/clients/cmdline/cl.h
M /branches/1.2.x/subversion/clients/cmdline/help-cmd.c
M /branches/1.2.x/subversion/clients/cmdline/main.c
M /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests.py
M /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn--help_stdout
M /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn_help_stdout
D /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn_ver-q_stderr
D /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn_ver-q_stdout
D /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn_version_stderr
D /branches/1.2.x/subversion/tests/clients/cmdline/getopt_tests_data/svn_version_stdout
Merge r14037 from trunk to 1.2.x branch.
Revert the addition of the "svn version" subcommand (r10430).
Votes:
+1: julianfoad, lundblad, dionisos
------------------------------------------------------------------------
r14102 | lundblad | 2005-04-11 06:46:16 -0500 (Mon, 11 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/clients/cmdline/main.c
Merge r14031, r14052 from trunk to 1.2.x branch.
Tweak help text for svn propset to include svn:needs-lock.
Approved by:
+1: lundblad, ringstrom, maxb
------------------------------------------------------------------------
r14092 | lundblad | 2005-04-11 01:26:50 -0500 (Mon, 11 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/clients/cmdline/main.c
Merge r14064 from trunk to 1.2.x branch.
Fix svn status help text - "*" appears in column 8, not 9.
Approved by:
+1: maxb, philip, ringstrom
------------------------------------------------------------------------
r14091 | lundblad | 2005-04-11 01:22:49 -0500 (Mon, 11 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_fs/fs-loader.c
Merge r14061 from trunk to 1.2.x branch.
Kill uninitialized struct member in libsvn_fs.
Approved by:
+1: lundblad, philip, ringstrom
------------------------------------------------------------------------
r14090 | lundblad | 2005-04-11 01:17:35 -0500 (Mon, 11 Apr 2005) | 7 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/libsvn_ra_dav/session.c
Merge r14057 from trunk to 1.2.x branch.
Fix a crash in ra_dav when a NULL lock comment is passed to svn_ra_lock.
Approved by:
+1: lundblad, philip, ringstrom
------------------------------------------------------------------------
r14035 | maxb | 2005-04-08 07:22:27 -0500 (Fri, 08 Apr 2005) | 6 lines
Changed paths:
M /branches/1.2.x/STATUS
M /branches/1.2.x/subversion/include/svn_error.h
M /branches/1.2.x/subversion/include/svn_error_codes.h
M /branches/1.2.x/subversion/include/svn_fs.h
M /branches/1.2.x/subversion/libsvn_fs_base/err.c
M /branches/1.2.x/subversion/libsvn_fs_base/err.h
M /branches/1.2.x/subversion/libsvn_fs_base/lock.c
M /branches/1.2.x/subversion/libsvn_fs_fs/err.c
M /branches/1.2.x/subversion/libsvn_fs_fs/err.h
M /branches/1.2.x/subversion/libsvn_fs_fs/lock.c
M /branches/1.2.x/subversion/libsvn_ra_dav/commit.c
Merge r14011 from trunk to 1.2.x branch.
Rename a locking error code for clarity (LOCKED -> ALREADY_LOCKED).
Approved by: +1: julianfoad, lundblad, fitz, dlr
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> > The total soak time of all release candidates in a minor line must
> > be at least 4 weeks. The last release candidate must have soaked
> > for at least 2 weeks before being promoted to a final release.
> >
> > Thoughts?
>
> We've already chosen 1 week as the minimum length of time for the final
> release candidate. See HACKING.
Yes, but I was treating that as contingent on other current soak
requirements. In other words, that requirement doesn't stand alone,
it's related to the rest of that section of HACKING.
However, reading it all again now, it leaves a lot of room for
judgement. As it should: it's the code that needs scrutinizing, more
than our rules.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2005-04-28 at 16:06, kfogel@collab.net wrote:
> My feeling is, if we're comfortable with a 3 week soak for RC2 --
> given additional testing -- then we ought to consider a more general
> policy change. Such as:
>
> The total soak time of all release candidates in a minor line must
> be at least 4 weeks. The last release candidate must have soaked
> for at least 2 weeks before being promoted to a final release.
>
> Thoughts?
We've already chosen 1 week as the minimum length of time for the final
release candidate. See HACKING.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by kf...@collab.net.
"Jostein Chr. Andersen" <jo...@josander.net> writes:
> If we look at we have called RC's so far, then the RC1 was of beta
> quality IMHO. So according to the old standards: reset the soak time -
> again IMHO.
(Fortunately, we're at leisure to discuss a soak time reduction even
as the soak time clock continues ticking!)
I'm somewhat uncomfortable with a 3 week soak for RC2. The real issue
is not the "beta" quality of RC1, but the amount of code churn on the
branch between RC1 and RC2, and the risk that some of that churn
introduced bugs that were not present in RC1. I'm willing to be
persuaded that 3 weeks is enough, especially with added intentional
testing, but... Well, read on.
During the week or so of RC1 soak, several bugs were found. At least
one of these was a fairly major bug on Windows, related the new
locking code -- under certain circumstances, it broke 'svn update'.
These circumstances were not a complete edge case, but they wouldn't
come up in most people's daily use of Subversion either. Thus,
although we might expect that such a bug on Windows would be caught by
lots and lots of people, IIRC only one user noticed it (or anyway, one
user reported it). Fortunately, Moisei was able to give us a good
reproduction recipe, so it was fixed in r14304.
That whole episode really made me think: it would have sucked to ship
with that bug, yet it was caught by just *one* user? True, it
happened early in the soak period, so maybe over a full four week
soak, others would have reported it too. But still...
I'm not -1'ing the 3-week proposal. Yet. I've started reviewing all
the merges onto the 1.2.x line between RC1 and RC2. I'd rather base
such a decision on a close examination of the changes in question,
than on vague, fuzzy feelings about code churn. If in the end I'm
still jittery about a shortened soak, and want to propose a full soak,
I'll at least have details to back it up. (One thing I wish we had
stats for is, how many -- and what sort of -- bugs were found in 1.1.0
during its final week of soak.) In the meantime, the clock is still
ticking, so we're not losing any ground.
On a more general note:
Subversion chose a 4 week soak time somewhat arbitrarily. Does
reducing it to 3 weeks reduce its effectiveness by one quarter?
Probably not, because bugs found toward the end of the soak are more
likely to be duplicates of bugs found earlier in the soak anyway.
Going from 4 to 3 reduces the soak's effectiveness by *some* amount,
but we really don't know how much.
My feeling is, if we're comfortable with a 3 week soak for RC2 --
given additional testing -- then we ought to consider a more general
policy change. Such as:
The total soak time of all release candidates in a minor line must
be at least 4 weeks. The last release candidate must have soaked
for at least 2 weeks before being promoted to a final release.
Thoughts?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn 1.2 resoak?
Posted by "Jostein Chr. Andersen" <jo...@josander.net>.
On Tuesday 26 April 2005 21.11, Ben Collins-Sussman wrote:
> So... now that svn 1.2.0-rc2 is released, there really hasn't been any
> formal discussion on this list about resetting the 1.2 "soak" time --
> just some informal irc chatter.
>
> Looking at the differences between rc1 and rc2, there were couple of
> really big bugs fixed (the svn:needs-lock bug on win32, and the FSFS
> race condition), and a bunch of small-to-medium-sized bugs (some crash
> fixes, some various behavior fixes, some reversions of new behaviors
> too).
If we look at we have called RC's so far, then the RC1 was of beta
quality IMHO. So according to the old standards: reset the soak time -
again IMHO.
Jostein
--
http://www.josander.net/en/contact/