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 Reser <be...@reser.org> on 2012/11/01 19:42:35 UTC
1.8 Progress
Looking at our roadmap we have the following things still in progress:
1) local moves/renames. Based on the conversation I had on IRC this seems
to be not done yet due to issues found in the original plan. stsp says
that if it can't be done before we want to otherwise release 1.8 he'd like
to pull the move code entirely. So the question here is do we wait for
some unknown amount of time for this to complete? Is this an important 1.8
feature?
2) Ev2. The notes say this is believed to be in a releasable state? Is
there any work needed to verify this? Do we need to remove the use of Ev2
in any place to avoid releasing with compatibility shims in use? Are we
comfortable that the API is complete?
3) libsvn_ra_serf stabilization. I know there have been a couple concerns
that Philip has raised (EAGAIN and the random failures). Plus there are
several issues here (not all of the issues here are serf issues):
http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&subcomponent=libsvn_ra_serf&subcomponent=libsvn_ra_neon
Who can drive these issues to completion? Is there any additional testing
work we should do to try and determine the stability of serf in light of
the fact that we're planning to remove neon?
4) Symmetric merge. Should be done per julianf.
5) Inherited properties/Server-dictated configuration. This is marked as
completed but I see some discussion over property names still ongoing.
6) Conflict storage. This is marked as done but there was discussion in
the past about needing a wc format bump? Where are we with that?
Beyond that we have the ordinary reviews of tests (pburba has said he's
working on this), new apis and issue triage (cmpilato seems to have been
doing some issue triage).
Also at the risk of opening a can of worms we need to decide on the wc
upgrade issue? I can say that the impression I got from Subversion Live
was that a lot of people use multiple clients and that auto-upgrade seems
bad. But we also discussed trying to handle reads from an older wcng style
wc without requiring a wc upgrade. Can someone drive this?
cmpilato started a previous thread on 1.8 progress but it got distracted
with some other issues. A number of the same questions were outstanding
then. So I'd appreciate if we can keep this thread focused on the issues
at hand and not things we'd like to see in the future that aren't on the
roadmap.
In particular I'd like to see the outcome of the thread be that we have
some idea what work we feel remains and who is going to be doing it.
Lastly I don't want to give the impression that I'm rushing 1.8. However,
I would like us to see us focus on the things we want to get done with 1.8.
Re: 1.8 Progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Thu, Nov 1, 2012 at 3:11 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 11/01/2012 02:42 PM, Ben Reser wrote:
>> 2) Ev2. The notes say this is believed to be in a releasable state? Is
>> there any work needed to verify this? Do we need to remove the use of Ev2
>> in any place to avoid releasing with compatibility shims in use? Are we
>> comfortable that the API is complete?
>
> Honestly, I'm a bit concerned that with Hyrum and Greg both effectively
> inactive, Ev2 runs the risk of appearing in our public API without any
> remaining active champions/implementors/maintainers of it. There's a
> non-zero fear factor here.
Understandably so. I've been trying to leave breadcrumbs and beg for
help over the past several months, but nobody has taken me up on it.
I've been hacking around on Ev2 as I can, but Real Life is leaving
little time for that these days. I can consult, direct and review,
but my hacking time is very limited.
We can always shuffle headers around or document the things as
experimental, so committing ourselves to the API as this point isn't
my concern. The only real limiting around Ev2 and 1.8 is issue #4116
which is svnrdump failures over ra_serf. In the issue, I propose
using Ev2 to get around the problem, since the dumpfile format is so
incongruent with the editor.
Of course, we don't *have* to do that, but as I've thought about it,
any solution will require a bit o' caching---which we've already
implemented as part of the Ev2 shims. We *might* be able to implement
the svnrdump editor as Ev2, shim the thing on the client side (which
gives us the required caching) and release that way. Or there might
be a better solution I'm overlooking because I've got Ev2 on the
brain.
>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>> that Philip has raised (EAGAIN and the random failures). Plus there are
>> several issues here (not all of the issues here are serf
>> issues):
>>
>> Who can drive these issues to completion? Is there any additional testing
>> work we should do to try and determine the stability of serf in light of
>> the fact that we're planning to remove neon?
>
> I've been steadily working on the ra_serf stuff, but there are some issues
> which appear to need some deeper focus by members of the Serf dev-team.
> Lieven mentioned a bit ago that he was planning to invest a block of time
> here soon (ApacheCon Europe hackathan, perhaps it was?) -- I'm hoping we'll
> see some significant progress on ra_serf stabilization as a result.
>
>> 5) Inherited properties/Server-dictated configuration. This is marked as
>> completed but I see some discussion over property names still ongoing.
>
> To the best of my knowledge, it's only this superficial property name
> discussion that's still unresolved.
>
>> Beyond that we have the ordinary reviews of tests (pburba has said he's
>> working on this), new apis and issue triage (cmpilato seems to have been
>> doing some issue triage).
>>
>> Also at the risk of opening a can of worms we need to decide on the wc
>> upgrade issue? I can say that the impression I got from Subversion Live was
>> that a lot of people use multiple clients and that auto-upgrade seems bad.
>> But we also discussed trying to handle reads from an older wcng style wc
>> without requiring a wc upgrade. Can someone drive this?
>
> I distinctly recall stsp offering to take up the charge on this. :-)
>
>> Lastly I don't want to give the impression that I'm rushing 1.8. However, I
>> would like us to see us focus on the things we want to get done with 1.8.
>
> Rushing 1.8? No, that's not this community's style. But I'm starting to
> see feedback from our user base that the slippage we've allowed in the
> release already is not inspiring confidence. I'm trying to keep my focus on
> 1.8. There are plenty of other things I'd love to get my fingers into
> (FSv2, master passphrase, etc.) but at some point we need to remain good
> stewards of our user base.
+1, and I'm sorry I can't help more.
Re: maunal WC upgrade test fallout
Posted by Ben Reser <be...@reser.org>.
On Fri, Nov 2, 2012 at 6:07 AM, Branko Čibej <br...@wandisco.com> wrote:
> During the SVN Live conferences I asked people, privately, about their
> opinion on automatic vs. manual upgrades. The overwhelming response was
> that they wait for all the clients to catch up before upgrading. Given
> these results, my opinion leans towards leaving auto-upgrades on, but
> spending more effort on documenting that there's no way back.
The impression I got was that the following two statements are true:
People would prefer auto-upgrading over a manual upgrade.
People had been negatively impacted due to auto-upgrades in the past.
While these two statements seem contradictory. Ultimately, what
people really want is to just not worry about it at all.
But that's not really possible. Especially in light of your following
statement:
> Regarding read-only access to old-format WCs: I studied the
> implementation and came to the conclusion that it's not worth the
> effort. There's no clear connection between read-only operations and
> actually not modifying the wc.db, so unless someone wants to refactor
> the WC code (and all the bits that rely on it) again, this is not going
> to happen.
My inclination is to use manual upgrades:
1) With auto-upgrades we can put warnings all over the place but if
the end user never reads it there's nothing we can do to help them.
So many of our users don't see our website or documentation, so the
only place we can really drive messages to them is through the error
messages we display. By requiring the manual upgrade when you try to
use the working copy with a newer client we can display a message
explaining the issues. It's not worry free for the user but at least
we have the opportunity to educate them.
2) This is a pretty weak argument but it seems really odd to me to
have an upgrade command in the client that's only used to go from 1.6
-> 1.7.
Re: maunal WC upgrade test fallout
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/02/2012 01:15 PM, Branko Čibej wrote:
> On 02.11.2012 15:15, C. Michael Pilato wrote:
>> What would have been more interesting to know is how they felt about the
>> required one-time manual 'svn upgrade' in 1.7 -- was it troublesome for
>> their processes?
>
> I got exactly one response about the 1.7 upgrade, and it went like this:
> "checked out new working copies because the upgrade didn't work for us."
> Which doesn't really help all that much in retrospect.
No, other than perhaps affirm what Mark Phippard said in earlier iterations
of this discussion topic about how the complaints he heard were generally
not of the "boo, manual upgrade is a pain" variety, but more like, "boo, the
upgrade failed in my scenario".
> Do we want to delay 1.8 until we /can/ do backward-compatible read-only
> operations? I somehow don't think so.
No.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: maunal WC upgrade test fallout
Posted by Branko Čibej <br...@wandisco.com>.
On 02.11.2012 15:15, C. Michael Pilato wrote:
> On 11/02/2012 09:07 AM, Branko Čibej wrote:
>> On 02.11.2012 04:34, Stefan Sperling wrote:
>>> On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
>>>> I went ahead and disabled auto-upgrades in r1404856.
>> During the SVN Live conferences I asked people, privately, about their
>> opinion on automatic vs. manual upgrades. The overwhelming response was
>> that they wait for all the clients to catch up before upgrading. Given
>> these results, my opinion leans towards leaving auto-upgrades on, but
>> spending more effort on documenting that there's no way back.
> I'm not convinced that your results (as presented, at least) actually tell
> us anything other than that our more-aware users already expect
> auto-upgrading to occur and to screw them over, so they avoid it. That's
> seems to fall quite a bit short of a validation of the auto-upgrade
> approach! ;-)
True.
> What would have been more interesting to know is how they felt about the
> required one-time manual 'svn upgrade' in 1.7 -- was it troublesome for
> their processes?
I got exactly one response about the 1.7 upgrade, and it went like this:
"checked out new working copies because the upgrade didn't work for us."
Which doesn't really help all that much in retrospect.
> If our more-aware users already work to upgrade their
> software in concert, and have no concerns with the manual 'svn upgrade'
> step, then our auto-or-not-upgrade decision is a moot point for them. Their
> opinion is, therefore, disinteresting.
>
> What remains, then, are our less-aware users, who'll -- if we decide to
> continue auto-upgrading -- will wind up fussing with all the inherent
> problems of mixed-pedigree Subversion clients and for whom extra
> documentation is pointless (because if they read *that*, they'd be more
> aware!). :-)
The real problem I see with manual upgrades is that you can do /nothing/
with the new client until you've upgraded your working copy. That's a
regression from what we did up to and including 1.6, but it's not easy
to fix because the WC-NG design does not really admit the concept of
read-only operations. Of course, in this respect automatic upgrades are
no better, just the other way around.
Do we want to delay 1.8 until we /can/ do backward-compatible read-only
operations? I somehow don't think so.
-- Brane
Re: maunal WC upgrade test fallout
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/02/2012 09:07 AM, Branko Čibej wrote:
> On 02.11.2012 04:34, Stefan Sperling wrote:
>> On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
>>> I went ahead and disabled auto-upgrades in r1404856.
>
> During the SVN Live conferences I asked people, privately, about their
> opinion on automatic vs. manual upgrades. The overwhelming response was
> that they wait for all the clients to catch up before upgrading. Given
> these results, my opinion leans towards leaving auto-upgrades on, but
> spending more effort on documenting that there's no way back.
I'm not convinced that your results (as presented, at least) actually tell
us anything other than that our more-aware users already expect
auto-upgrading to occur and to screw them over, so they avoid it. That's
seems to fall quite a bit short of a validation of the auto-upgrade
approach! ;-)
What would have been more interesting to know is how they felt about the
required one-time manual 'svn upgrade' in 1.7 -- was it troublesome for
their processes? If our more-aware users already work to upgrade their
software in concert, and have no concerns with the manual 'svn upgrade'
step, then our auto-or-not-upgrade decision is a moot point for them. Their
opinion is, therefore, disinteresting.
What remains, then, are our less-aware users, who'll -- if we decide to
continue auto-upgrading -- will wind up fussing with all the inherent
problems of mixed-pedigree Subversion clients and for whom extra
documentation is pointless (because if they read *that*, they'd be more
aware!). :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: maunal WC upgrade test fallout
Posted by Branko Čibej <br...@wandisco.com>.
On 02.11.2012 04:34, Stefan Sperling wrote:
> On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
>> I went ahead and disabled auto-upgrades in r1404856.
During the SVN Live conferences I asked people, privately, about their
opinion on automatic vs. manual upgrades. The overwhelming response was
that they wait for all the clients to catch up before upgrading. Given
these results, my opinion leans towards leaving auto-upgrades on, but
spending more effort on documenting that there's no way back.
Regarding read-only access to old-format WCs: I studied the
implementation and came to the conclusion that it's not worth the
effort. There's no clear connection between read-only operations and
actually not modifying the wc.db, so unless someone wants to refactor
the WC code (and all the bits that rely on it) again, this is not going
to happen.
> This caused some test fallout which should be mostly fixed now.
> The main issue was that I temporarily broke most of the tests
> when run within a 1.7 WC.
>
> The only remaining issue I'm aware of is that upgrade_tests.py
> ends up upgrading the parent WC during the test run. I'm not quite
> sure yet what we can do to prevent that.
Sounds like a bug in either the test code, or the bits of wc-ng that try
to determine the wc root...
-- Brane
maunal WC upgrade test fallout (was: Re: 1.8 Progress)
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Nov 02, 2012 at 02:59:10AM +0100, Stefan Sperling wrote:
> I went ahead and disabled auto-upgrades in r1404856.
This caused some test fallout which should be mostly fixed now.
The main issue was that I temporarily broke most of the tests
when run within a 1.7 WC.
The only remaining issue I'm aware of is that upgrade_tests.py
ends up upgrading the parent WC during the test run. I'm not quite
sure yet what we can do to prevent that.
Re: 1.8 Progress
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 01, 2012 at 03:11:57PM -0400, C. Michael Pilato wrote:
> On 11/01/2012 02:42 PM, Ben Reser wrote:
> > Also at the risk of opening a can of worms we need to decide on the wc
> > upgrade issue? I can say that the impression I got from Subversion Live was
> > that a lot of people use multiple clients and that auto-upgrade seems bad.
> > But we also discussed trying to handle reads from an older wcng style wc
> > without requiring a wc upgrade. Can someone drive this?
>
> I distinctly recall stsp offering to take up the charge on this. :-)
I went ahead and disabled auto-upgrades in r1404856.
This doesn't preclude the option of re-enabling auto-upgrade in case we
can somehow get read-only operations to work without requiring an upgrade.
If there's any further discussion to be had on this I'm happy to participate.
Re: 1.8 Progress
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/01/2012 02:42 PM, Ben Reser wrote:
> 2) Ev2. The notes say this is believed to be in a releasable state? Is
> there any work needed to verify this? Do we need to remove the use of Ev2
> in any place to avoid releasing with compatibility shims in use? Are we
> comfortable that the API is complete?
Honestly, I'm a bit concerned that with Hyrum and Greg both effectively
inactive, Ev2 runs the risk of appearing in our public API without any
remaining active champions/implementors/maintainers of it. There's a
non-zero fear factor here.
> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures). Plus there are
> several issues here (not all of the issues here are serf
> issues):
>
> Who can drive these issues to completion? Is there any additional testing
> work we should do to try and determine the stability of serf in light of
> the fact that we're planning to remove neon?
I've been steadily working on the ra_serf stuff, but there are some issues
which appear to need some deeper focus by members of the Serf dev-team.
Lieven mentioned a bit ago that he was planning to invest a block of time
here soon (ApacheCon Europe hackathan, perhaps it was?) -- I'm hoping we'll
see some significant progress on ra_serf stabilization as a result.
> 5) Inherited properties/Server-dictated configuration. This is marked as
> completed but I see some discussion over property names still ongoing.
To the best of my knowledge, it's only this superficial property name
discussion that's still unresolved.
> Beyond that we have the ordinary reviews of tests (pburba has said he's
> working on this), new apis and issue triage (cmpilato seems to have been
> doing some issue triage).
>
> Also at the risk of opening a can of worms we need to decide on the wc
> upgrade issue? I can say that the impression I got from Subversion Live was
> that a lot of people use multiple clients and that auto-upgrade seems bad.
> But we also discussed trying to handle reads from an older wcng style wc
> without requiring a wc upgrade. Can someone drive this?
I distinctly recall stsp offering to take up the charge on this. :-)
> Lastly I don't want to give the impression that I'm rushing 1.8. However, I
> would like us to see us focus on the things we want to get done with 1.8.
Rushing 1.8? No, that's not this community's style. But I'm starting to
see feedback from our user base that the slippage we've allowed in the
release already is not inspiring confidence. I'm trying to keep my focus on
1.8. There are plenty of other things I'd love to get my fingers into
(FSv2, master passphrase, etc.) but at some point we need to remain good
stewards of our user base.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: Progress on update-move [was: 1.8 Progress]
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Jan 17, 2013 at 02:55:50PM +0100, Stefan Sperling wrote:
> What would also help is some UI design that specifies which kinds of
> tree conflicts we expect 1.8 to resolve automatically during 'svn
> resolve', and how such cases are resolved depending on what options
> the user is choosing.
Actually, UI design is only part of this. Another part is behavioural
specification for several tree conflict resolution cases. The UI design
should follow from there.
Re: Progress on update-move [was: 1.8 Progress]
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jan 16, 2013 at 07:50:57PM +0000, Julian Foad wrote:
> Philip Martin wrote:
>
> > Some remaining tasks:
> >
> > - delete should remove working items
> >
> > - notifications
> >
> > - switch instead of update
>
> r1434352 teaches it to record a 'switch' as such.
>
> - Julian
>
> > - finite depth update conflict
> >
> > - tests (may need notifications)
> >
> > I plan to work on delete next.
What would also help is some UI design that specifies which kinds of
tree conflicts we expect 1.8 to resolve automatically during 'svn
resolve', and how such cases are resolved depending on what options
the user is choosing.
Currently, --accept=mine-conflict (and the corresponding 'mine-conflict'
answer at the interactive conflict prompt) maps to updating a locally
moved away file or directory after a tree conflict, which is flagged on
the moved-away directory after an update/switch. This is what Philip is
talking about above.
We should also implement --accept=theirs-conflict for this case, and
define the desired behaviour (I've added two tests for this, see
r1434665 and r1434668).
Do we want to keep using mine-conflict and theirs-conflict like this?
Is this a good UI, or should we rename these options?
Should offer similar options for additional tree conflict cases in 1.8,
or do we defer that to 1.9? If we defer, are we expecting the options we
put into the UI for 1.8 to still work in the exact same way in 1.9?
Ideally, we should have a decent idea about the UI we're aiming for
once we have implemented 'interactive tree conflict resolution' in
the best possible way for as many tree conflict cases as possible.
I'm not that good at UI design so I am looking for some help :)
Progress on update-move [was: 1.8 Progress]
Posted by Julian Foad <ju...@btopenworld.com>.
Philip Martin wrote:
> Some remaining tasks:
>
> - delete should remove working items
>
> - notifications
>
> - switch instead of update
r1434352 teaches it to record a 'switch' as such.
- Julian
> - finite depth update conflict
>
> - tests (may need notifications)
>
> I plan to work on delete next.
Re: 1.8 Progress
Posted by Ben Reser <be...@reser.org>.
On Wed, Jan 16, 2013 at 7:16 AM, Philip Martin
<ph...@wandisco.com> wrote:
> - delete should remove working items
>
> - notifications
>
> - switch instead of update
>
> - finite depth update conflict
>
> - tests (may need notifications)
I've been working on some test stuff.
I'll send an email shortly with some questions and issues.
Re: 1.8 Progress
Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:
> Is there a chunk of this work that can be easily subcontracted out to
> another of us devs? Tests are probably the obvious option, assuming that
> there lives someplace public a thorough enough design doc from which to work
> when coding test expectations.
The high-level veiw of this feature is that if the local edits in:
svn mv ...
svn mv ...
local edits to move destination
svn up
causes update to generate tree-conflicts on the move source then running
svn resolve --accept mine-conflict
on the tree-conflicts (possibly multiple times if there are nested
moves) resolves the tree-conflicts by updating the move destination so
that the final state is as if the update was done before the moves:
svn up
svn mv ...
svn mv ...
local edits to move destination
The result is that the moves can be committed and look like moves.
There may still be conflicts in the final state: text and/or property if
the incoming changes cannot be merged with the local edits, and tree if
the local edits obstruct the incoming changes.
Some remaining tasks:
- delete should remove working items
- notifications
- switch instead of update
- finite depth update conflict
- tests (may need notifications)
I plan to work on delete next.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: 1.8 Progress
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/02/2013 01:07 PM, Philip Martin wrote:
> Things that need more work:
>
> - tests.
>
> - handling deleting files/dirs from the working files, at present they
> are left unversioned.
>
> - handle an update that makes no text/property/tree changes in the
> move source, probably by creating a tree-conflict during the
> post-drive revision bump.
>
> - switch can cause the tree-conflicts on the move source, at present
> the new code hard-codes 'update'.
>
> - more tests (again).
Is there a chunk of this work that can be easily subcontracted out to
another of us devs? Tests are probably the obvious option, assuming that
there lives someplace public a thorough enough design doc from which to work
when coding test expectations.
What about some of the other tasks? Could Bert (for example) do some WC-NG
query wrangling or something for one or more of these subtasks?
I don't see a documentation task in the above list -- what will we wish to
brag about in the release notes, and what will need documentation in the
book? (I'm in an svnbook frame of mind right now, so perhaps that's a
subtask I can help with personally.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
RE: 1.8 Progress
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: vrijdag 4 januari 2013 16:07
> To: Bert Huijben
> Cc: 'Julian Foad'; Michael Pilato; 'Stefan Sperling'; 'Ben Reser';
'Subversion
> Development'
> Subject: Re: 1.8 Progress
>
> "Bert Huijben" <be...@qqmail.nl> writes:
>
> >> -----Original Message-----
> >> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> >>
> >> - handle an update that makes no text/property/tree changes in the
> >> move source, probably by creating a tree-conflict during the
> >> post-drive revision bump.
> >
> > So, create a tree conflict on *every* update?
> >
> > If there is no change I would just bump the copyfrom revision. Making
> every
> > update of a working copy after a move a tree conflict is not what I
would
> > expect as a Subversion user.
> >
> > I wouldn't call that a releasable state for 1.8.
>
> Looking at this a bit more I see that the post-drive changes are made
> within a single transaction so most updates don't need a tree-conflict,
> it can be resolved automatically. The only time a tree-conflict might
> be needed is on the rare occasions that the update results in a
> mixed-revision move source.
And in this case I fully agree that we should introduce a tree conflict and
a path to recover from this problem.
(Probably fix the conflict/obstruction that made the update skip the nodes,
followed by running update again)
But there shouldn't be many scenarios where this happens.
As far as I can tell a moved away node can only be obstructed by an
obstructing working copy. Even conflicts on the move-from-root should allow
BASE being updated. (In all other scenarios the node is shadowed and we
still update BASE)
Hmm... and even then, in the post update bump we handle everything in-db, so
we don't check for obstructing working copies because we use wcroot, relpath
for processing.
So, which skip scenario would then remain?
Bert
Re: 1.8 Progress
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
>> -----Original Message-----
>> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
>>
>> - handle an update that makes no text/property/tree changes in the
>> move source, probably by creating a tree-conflict during the
>> post-drive revision bump.
>
> So, create a tree conflict on *every* update?
>
> If there is no change I would just bump the copyfrom revision. Making every
> update of a working copy after a move a tree conflict is not what I would
> expect as a Subversion user.
>
> I wouldn't call that a releasable state for 1.8.
Looking at this a bit more I see that the post-drive changes are made
within a single transaction so most updates don't need a tree-conflict,
it can be resolved automatically. The only time a tree-conflict might
be needed is on the rare occasions that the update results in a
mixed-revision move source.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
RE: 1.8 Progress
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: woensdag 2 januari 2013 19:07
> To: Julian Foad
> Cc: C. Michael Pilato; Stefan Sperling; Ben Reser; Subversion Development
> Subject: Re: 1.8 Progress
>
> Philip Martin <ph...@wandisco.com> writes:
>
> > I still think we may get something working by the end of the year. The
> > simple cases will work and should be useful. The more complex cases
> > should also work to some extent, but it's possible that some subsequent
> > tree-conflicts that should be detected while resolving the first
> > tree-conflict may get missed.
>
> This now works to a certain extent. When an update attempts to apply
> changes to a moved tree it causes a tree-conflict on the move source
> just like 1.7. When resolving the tree-conflict the user can choose to
> apply the changes to the move destination and this now updates the NODES
> rows for the move destination and merges the changes in the working
> files. This may in turn generate tree-conflicts in the move destination
> for nested moves, deletes, obstructions. For nested moves the
> tree-conflict can also be resolved by applying the changes to the move
> destination.
>
> Things that need more work:
>
> - tests.
>
> - handling deleting files/dirs from the working files, at present they
> are left unversioned.
>
> - handle an update that makes no text/property/tree changes in the
> move source, probably by creating a tree-conflict during the
> post-drive revision bump.
So, create a tree conflict on *every* update?
If there is no change I would just bump the copyfrom revision. Making every
update of a working copy after a move a tree conflict is not what I would
expect as a Subversion user.
I wouldn't call that a releasable state for 1.8.
>
> - switch can cause the tree-conflicts on the move source, at present
> the new code hard-codes 'update'.
>
> - more tests (again).
Bert
Re: 1.8 Progress
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> I still think we may get something working by the end of the year. The
> simple cases will work and should be useful. The more complex cases
> should also work to some extent, but it's possible that some subsequent
> tree-conflicts that should be detected while resolving the first
> tree-conflict may get missed.
This now works to a certain extent. When an update attempts to apply
changes to a moved tree it causes a tree-conflict on the move source
just like 1.7. When resolving the tree-conflict the user can choose to
apply the changes to the move destination and this now updates the NODES
rows for the move destination and merges the changes in the working
files. This may in turn generate tree-conflicts in the move destination
for nested moves, deletes, obstructions. For nested moves the
tree-conflict can also be resolved by applying the changes to the move
destination.
Things that need more work:
- tests.
- handling deleting files/dirs from the working files, at present they
are left unversioned.
- handle an update that makes no text/property/tree changes in the
move source, probably by creating a tree-conflict during the
post-drive revision bump.
- switch can cause the tree-conflicts on the move source, at present
the new code hard-codes 'update'.
- more tests (again).
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: 1.8 Progress
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@btopenworld.com> writes:
> Stefan Sperling wrote:
>
>> On Thu, Nov 29, 2012 at 04:52:15PM -0500, C. Michael Pilato wrote:
> [...]
>>> OWNERSHIP: Given Philip's comment, I believe it is reasonable to
>>> deem him the owner of this body of work, or at least co-owner with
>>> a possibly-time-constrained Stefan. But perhaps all there is to
>>> "own" is the post-branch removal of the feature?
>>
>> I'd prefer to get moves on trunk into a releasable state, or cut
>> the feature out on trunk and put it back in after branching 1.8.
>> I believe removing the feature would be somewhat invasive so it makes
>> sense to do so on trunk in several steps, rather than on the release
>> branch which is supposed to be stable at the time it is created.
>>
>> Obviously, fixing updates of moves would be even better :)
>> I hope Philip or someone else can find time for this.
>
> I'm going to try to help with this, this week and next week.
I still think we may get something working by the end of the year. The
simple cases will work and should be useful. The more complex cases
should also work to some extent, but it's possible that some subsequent
tree-conflicts that should be detected while resolving the first
tree-conflict may get missed.
I'm struggling with my wc-fu at the moment: all the code I write appears
to corrupt wc.db. I'm going to break up my patch into smaller bits.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: 1.8 Progress
Posted by Julian Foad <ju...@btopenworld.com>.
Stefan Sperling wrote:
> On Thu, Nov 29, 2012 at 04:52:15PM -0500, C. Michael Pilato wrote:
[...]
>> OWNERSHIP: Given Philip's comment, I believe it is reasonable to
>> deem him the owner of this body of work, or at least co-owner with
>> a possibly-time-constrained Stefan. But perhaps all there is to
>> "own" is the post-branch removal of the feature?
>
> I'd prefer to get moves on trunk into a releasable state, or cut
> the feature out on trunk and put it back in after branching 1.8.
> I believe removing the feature would be somewhat invasive so it makes
> sense to do so on trunk in several steps, rather than on the release
> branch which is supposed to be stable at the time it is created.
>
> Obviously, fixing updates of moves would be even better :)
> I hope Philip or someone else can find time for this.
I'm going to try to help with this, this week and next week.
- Julian
> I'll definitely get back to this in January, see where things are
> at that point, and move forward into whatever direction seems reasaonable.
>
Re: 1.8 Progress
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Nov 29, 2012 at 04:52:15PM -0500, C. Michael Pilato wrote:
> I also seem to recall Stefan also saying something about not having time to
> work on this stuff for the remainder of 2012, but I can't find a reference
> for that at the moment, so perhaps I just misremembered.
I said so on IRC. I'm fully booked by elego customers for most of each
week until Christmas, which is why I don't have much time I can invest
into Subversion this month.
> OWNERSHIP: Given Philip's comment, I believe it is reasonable to deem him
> the owner of this body of work, or at least co-owner with a
> possibly-time-constrained Stefan. But perhaps all there is to "own" is the
> post-branch removal of the feature?
I'd prefer to get moves on trunk into a releasable state, or cut
the feature out on trunk and put it back in after branching 1.8.
I believe removing the feature would be somewhat invasive so it makes
sense to do so on trunk in several steps, rather than on the release
branch which is supposed to be stable at the time it is created.
Obviously, fixing updates of moves would be even better :)
I hope Philip or someone else can find time for this.
I'll definitely get back to this in January, see where things are
at that point, and move forward into whatever direction seems reasaonable.
Re: 1.8 Progress
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Nov 29, 2012 at 4:52 PM, C. Michael Pilato <cm...@collab.net> wrote:
> [I'm going to try to summarize the body of responses generated from this
> original query -- a conversational reset, if you will -- so as to keep this
> line of inquiry moving toward closure.]
>
>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>> that Philip has raised (EAGAIN and the random failures).
>
> Philip and Ivan both seem keen on reinstating ra_neon.
>
> Justin poopooed the idea of reinstating ra_neon simply to get 100% feature
> coverage, suggesting that the way forward for the believed-to-be-small
> fraction of folks depending on Neon-specific features is to just stick with
> 1.7. (Not sure how serious he was.)
>
> Mark expanded the scope of the discussion to include Serf's affect on
> servers (growth of server logs, expanded number of server connections, etc.).
Just for the record, I believe someone else raised the log issue this
time and I merely participated in the ideas around how the log entries
might be controlled. I did raise the connection issue. I pointed out
that our testing revealed that KeepAlive and caching made it
manageable but without that it could be a problem. Stefan K.
indicated there might be Windows SSPI scenarios where this could be a
problem.
For the record, I feel like we already have made the decision on Neon
and need to move forward to get Serf ready.
One thing you did not mention (but I see has now been brought up in
the replies) is that I re-raised Ivan's suggestion about making Serf
have a way where it behaves like Neon during checkout/update. Since
you said you are working on it, I will just say how I would like to
see it work:
* When talking to pre-1.8 servers it should always behave like a Neon client.
* When talking to a 1.8+ server it should behave like a Neon client by default
* The server should support a directive that tells the client it can
open multiple connections and just fetch a skelta. I would assume the
server would advertise this in OPTIONS and the client would then
behave accordingly. We could conceivably use the existing Neon
directive for this (SVNAllowBulkUpdates), which would even work for
older servers I guess, but given that this directive would negatively
effect Neon clients (since Neon does not handle this mode as well as
Serf) perhaps it should be a new directive.
This would allow server administrators to have some control over how
their server was accessed and make the decision that is best for their
environment and workload. For administrators that are concerned about
log size or connections they can avoid that problem and the new
behavior would become an opt-in feature for administrators that want
the new features and can benefit from them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: 1.8 Progress
Posted by Branko Čibej <br...@wandisco.com>.
On 30.11.2012 02:15, Gavin Baumanis wrote:
> [...]
>>> 3) libsvn_ra_serf stabilization. I know there have been a couple
>>> concerns that Philip has raised (EAGAIN and the random failures).
>> Philip and Ivan both seem keen on reinstating ra_neon.
> [GB: ] Hi Everyone,
> I realise I am non-committer to SVN - but am a Software Developer none the less;
> I think it is important - regardless of the route chosen to make a firm decision and stick to it.
> The do we / don't we get rid of ra_neon has been a talking point on here for a really long time now and seemingly still has no "final" status.
Hear hear.
> I'd also like to add, that if the end-game is; we are going to "just" support serf, then surely the answer is to spend time correcting the issues in serf that people have noted, as opposed to spending time re-inserting neon?
> Of course that assumes that we can get serf to where it needs to be - in time for a 1.8 release.
>
> It might just be stating the obvious - but if we can’t get serf to where it needs to be for a 1.8 release of SVN - then surely it is prudent to re-insert ra_neon back into SVN and make 1.9 the goal for being serf-only?
Doing this will make that goal never happen. I disagree with the idea
that Serf is not ready for release for one reason or another. The
important issues all have solutions, and bugs will happen regardless of
how long we wait.
As gstein has said innumerable times, if you don't get people to use it,
it won't get tested. And in the long run, there's no question that the
ra_serf design is superior to whatever we could do with Neon.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
RE: 1.8 Progress
Posted by Gavin Baumanis <ga...@thespidernet.com>.
[...]
> > 3) libsvn_ra_serf stabilization. I know there have been a couple
> > concerns that Philip has raised (EAGAIN and the random failures).
>
> Philip and Ivan both seem keen on reinstating ra_neon.
[GB: ] Hi Everyone,
I realise I am non-committer to SVN - but am a Software Developer none the less;
I think it is important - regardless of the route chosen to make a firm decision and stick to it.
The do we / don't we get rid of ra_neon has been a talking point on here for a really long time now and seemingly still has no "final" status.
I'd also like to add, that if the end-game is; we are going to "just" support serf, then surely the answer is to spend time correcting the issues in serf that people have noted, as opposed to spending time re-inserting neon?
Of course that assumes that we can get serf to where it needs to be - in time for a 1.8 release.
It might just be stating the obvious - but if we can’t get serf to where it needs to be for a 1.8 release of SVN - then surely it is prudent to re-insert ra_neon back into SVN and make 1.9 the goal for being serf-only?
Gavin.
Re: 1.8 Progress
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/30/2012 01:24 PM, C. Michael Pilato wrote:
> On 11/30/2012 01:18 PM, Ivan Zhakov wrote:
>> On Fri, Nov 30, 2012 at 8:59 PM, C. Michael Pilato <cm...@collab.net> wrote:
>>> I'm adding send-all support to ra_serf right now, but will leave it #if'd
>>> out until we decide in what scenarios we wish to use it.
>>>
>> Wow! That's great! Are you going to add it to existing code or
>> implement separate update_editor? Implementing separate update_editor
>> may be better since current implementation is extremely overloaded.
>
> I suspect right now that there's far too much in common between the two
> implementations for me to justify a separate "editor". (Though, by "editor"
> I assume you mean only the XML-to-editor layer which lives in
> ra_serf/update.c, not the update editor itself.)
Committed in r1415864 (but currently disabled).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: 1.8 Progress
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/30/2012 01:18 PM, Ivan Zhakov wrote:
> On Fri, Nov 30, 2012 at 8:59 PM, C. Michael Pilato <cm...@collab.net> wrote:
>> I'm adding send-all support to ra_serf right now, but will leave it #if'd
>> out until we decide in what scenarios we wish to use it.
>>
> Wow! That's great! Are you going to add it to existing code or
> implement separate update_editor? Implementing separate update_editor
> may be better since current implementation is extremely overloaded.
I suspect right now that there's far too much in common between the two
implementations for me to justify a separate "editor". (Though, by "editor"
I assume you mean only the XML-to-editor layer which lives in
ra_serf/update.c, not the update editor itself.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: 1.8 Progress
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Nov 30, 2012 at 8:59 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 11/30/2012 09:44 AM, Ivan Zhakov wrote:
>> On Fri, Nov 30, 2012 at 1:52 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> [I'm going to try to summarize the body of responses generated from this
>>> original query -- a conversational reset, if you will -- so as to keep this
>>> line of inquiry moving toward closure.]
>>>
>> [..]
>>
>>>
>>>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>>>> that Philip has raised (EAGAIN and the random failures).
>>>
>>> Philip and Ivan both seem keen on reinstating ra_neon.
>>>
>> While I was strongly against making ra_serf as default in svn 1.7, I
>> don't remember that I suggested to reinstate ra_neon.
>
> Oops! Sorry for misrepresenting you views!
>
No problem :)
>> I believe that most of the issues comes from the skelta mode (XML
>> report with many PROPFINDs/GETs) update editor implementation in
>> ra_serf.
>
> [...]
>
>> We already reduced number of requests for 1.8 servers, so may be we
>> can choose to use "skelta mode" for 1.8 servers and non-skelta
>> (ra_neon style) for pre-1.8 servers?
>
> I'm adding send-all support to ra_serf right now, but will leave it #if'd
> out until we decide in what scenarios we wish to use it.
>
Wow! That's great! Are you going to add it to existing code or
implement separate update_editor? Implementing separate update_editor
may be better since current implementation is extremely overloaded.
--
Ivan Zhakov
Re: 1.8 Progress
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 11/30/2012 09:44 AM, Ivan Zhakov wrote:
> On Fri, Nov 30, 2012 at 1:52 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> [I'm going to try to summarize the body of responses generated from this
>> original query -- a conversational reset, if you will -- so as to keep this
>> line of inquiry moving toward closure.]
>>
> [..]
>
>>
>>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>>> that Philip has raised (EAGAIN and the random failures).
>>
>> Philip and Ivan both seem keen on reinstating ra_neon.
>>
> While I was strongly against making ra_serf as default in svn 1.7, I
> don't remember that I suggested to reinstate ra_neon.
Oops! Sorry for misrepresenting you views!
> I believe that most of the issues comes from the skelta mode (XML
> report with many PROPFINDs/GETs) update editor implementation in
> ra_serf.
[...]
> We already reduced number of requests for 1.8 servers, so may be we
> can choose to use "skelta mode" for 1.8 servers and non-skelta
> (ra_neon style) for pre-1.8 servers?
I'm adding send-all support to ra_serf right now, but will leave it #if'd
out until we decide in what scenarios we wish to use it.
>> OWNERSHIP: I can claim ownership of the ra_serf side of things if
>> Lieven and Ivan (or others) can step up to advise me and to cover the
>> Serf part itself.
> I'm ready to help you!
Awesome. Thanks.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: 1.8 Progress
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Nov 30, 2012 at 1:52 AM, C. Michael Pilato <cm...@collab.net> wrote:
> [I'm going to try to summarize the body of responses generated from this
> original query -- a conversational reset, if you will -- so as to keep this
> line of inquiry moving toward closure.]
>
[..]
>
>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>> that Philip has raised (EAGAIN and the random failures).
>
> Philip and Ivan both seem keen on reinstating ra_neon.
>
While I was strongly against making ra_serf as default in svn 1.7, I
don't remember that I suggested to reinstate ra_neon.
I believe that most of the issues comes from the skelta mode (XML
report with many PROPFINDs/GETs) update editor implementation in
ra_serf.
So compromise solution is to implement non-skelta mode in ra_serf and
make it default in svn 1.8. In this case some issues will be solved
automatically. Like:
* handling events on each open connection regularly.
* handling "408 Request Time-out" responses
* growth of server logs, expanded number of server connections
We already reduced number of requests for 1.8 servers, so may be we
can choose to use "skelta mode" for 1.8 servers and non-skelta
(ra_neon style) for pre-1.8 servers?
> OWNERSHIP: I can claim ownership of the ra_serf side of things if
> Lieven and Ivan (or others) can step up to advise me and to cover the
> Serf part itself.
I'm ready to help you!
--
Ivan Zhakov
Re: 1.8 Progress
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Thu, Nov 29, 2012 at 4:52 PM, C. Michael Pilato <cm...@collab.net>wrote:
>
> > 2) Ev2. The notes say this is believed to be in a releasable state? Is
> > there any work needed to verify this? Do we need to remove the use of
> Ev2
> > in any place to avoid releasing with compatibility shims in use? Are we
> > comfortable that the API is complete?
>
> Julian expressed doubt about whether the API was ready for prime-time.
>
> C-Mike expressed concern about the extremely low bus factor.
>
> Hyrum acknowledged both, and continued with: "We can always shuffle
> headers
> around or document the things as experimental, so committing ourselves to
> the API as this point isn't my concern. The only real limiting around Ev2
> and 1.8 is issue #4116 which is svnrdump failures over ra_serf. In the
> issue, I propose using Ev2 to get around the problem, since the dumpfile
> format is so incongruent with the editor. Of course, we don't *have* to do
> that, but as I've thought about it, any solution will require a bit o'
> caching---which we've already implemented as part of the Ev2 shims. We
> *might* be able to implement the svnrdump editor as Ev2, shim the thing on
> the client side (which gives us the required caching) and release that way.
> Or there might be a better solution I'm overlooking because I've got Ev2
> on
> the brain."
>
This is basically boils down to "rdump isn't completely Delta Editor
friendly, which interacts badly with Serf." This problem is only
tangentially related to Ev2, but it was proposed as one of the possible
solutions. It's probably better to try and pursue other solutions to this
independent of Ev2.
As for Ev2 itself, I don't see anything that should be blocking 1.8. If
people are uncomfortable shipping the API, some documentation and/or header
hackery should be sufficient to make it mutable in future releases. As far
as I know, all the Ev2 work is entirely self-contained within Subversion.
OWNERSHIP: Hyrum's got the most experience here, but due to his time
> contention, we may very well have no owner for this at all. That's bad.
Sadly, true.
-Hyrum
Re: 1.8 Progress
Posted by "C. Michael Pilato" <cm...@collab.net>.
[I'm going to try to summarize the body of responses generated from this
original query -- a conversational reset, if you will -- so as to keep this
line of inquiry moving toward closure.]
On 11/01/2012 02:42 PM, Ben Reser wrote:
> Looking at our roadmap we have the following things still in progress:
>
> 1) local moves/renames. Based on the conversation I had on IRC this seems
> to be not done yet due to issues found in the original plan. stsp says that
> if it can't be done before we want to otherwise release 1.8 he'd like to
> pull the move code entirely. So the question here is do we wait for some
> unknown amount of time for this to complete? Is this an important 1.8 feature?
Philip sez: "I'd like to get this in. The local-move/incoming-edit stuff
is not a huge task, I think we could get it working before the end of the year."
Stefan Sperling later responded (in another thread): "Well, I'm starting to
think that we underestimated the size of the problem (again, as we did in
1.6), and should probably try to find a correct design before writing more
code for this (except maybe XFAILing tests). Which means we should be
prepared to pull the moves feature from the 1.8.x branch once it is
branched, since move tracking doesn't provide any benefit if moves cannot be
updated properly. I don't think we can get this done before 1.9..."
I also seem to recall Stefan also saying something about not having time to
work on this stuff for the remainder of 2012, but I can't find a reference
for that at the moment, so perhaps I just misremembered.
OWNERSHIP: Given Philip's comment, I believe it is reasonable to deem him
the owner of this body of work, or at least co-owner with a
possibly-time-constrained Stefan. But perhaps all there is to "own" is the
post-branch removal of the feature?
> 2) Ev2. The notes say this is believed to be in a releasable state? Is
> there any work needed to verify this? Do we need to remove the use of Ev2
> in any place to avoid releasing with compatibility shims in use? Are we
> comfortable that the API is complete?
Julian expressed doubt about whether the API was ready for prime-time.
C-Mike expressed concern about the extremely low bus factor.
Hyrum acknowledged both, and continued with: "We can always shuffle headers
around or document the things as experimental, so committing ourselves to
the API as this point isn't my concern. The only real limiting around Ev2
and 1.8 is issue #4116 which is svnrdump failures over ra_serf. In the
issue, I propose using Ev2 to get around the problem, since the dumpfile
format is so incongruent with the editor. Of course, we don't *have* to do
that, but as I've thought about it, any solution will require a bit o'
caching---which we've already implemented as part of the Ev2 shims. We
*might* be able to implement the svnrdump editor as Ev2, shim the thing on
the client side (which gives us the required caching) and release that way.
Or there might be a better solution I'm overlooking because I've got Ev2 on
the brain."
OWNERSHIP: Hyrum's got the most experience here, but due to his time
contention, we may very well have no owner for this at all. That's bad.
> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures).
Philip and Ivan both seem keen on reinstating ra_neon.
Justin poopooed the idea of reinstating ra_neon simply to get 100% feature
coverage, suggesting that the way forward for the believed-to-be-small
fraction of folks depending on Neon-specific features is to just stick with
1.7. (Not sure how serious he was.)
Mark expanded the scope of the discussion to include Serf's affect on
servers (growth of server logs, expanded number of server connections, etc.).
Lieven, in a neighboring thread
(http://svn.haxx.se/dev/archive-2012-11/0225.shtml), enumerated a number of
specific observed problems with ra_serf:
> 1. When a very low Timeout is set in the apache server configuration,
> the server truncates response bodies in some situations
There appears to be a fix for the more egregious of these situations
in serf already, but Lieven indicated he'd look into this one.
> 2. ra_serf consumes way too much memory while doing large checkout's
> (issue #4196).
I believe I've finally fixed this with my commits to ra_serf on trunk
this week.
> 3. Ivan added a potential issue because ra_serf+serf are not handling
> events on each open connection regularly. This can result in timeouts,
Ivan submitted a patch for a portion of this work
(http://svn.haxx.se/dev/archive-2012-11/0193.shtml), but either way
it's not clear if this problem is theoretical only or has been observed.
> 4. Ivan further observed that the spillbuf mechanism, used to keep
> ra_serf reading from the REPORT connection while waiting for slow disc
> i/o, has two drawbacks:
> 4a. the amount of data stored in the spillbuf can get very large
> when processing the REPORT response is paused. When resuming, all
> data in the spillbuf is read and processed in one go. As this can
> be 1MB+ it can take a while, potentially timing out the REPORT
> response connection -> svn will stop.
> 4b. The GET and PROPFIND requests resulting from parsing that big
> chunk of data will all be sent on the same connection, where we
> have 4 available to send more requests in parallel.
(I've nothing to add to this.)
> 5. In one of Philip error-reporting mails, there was mention of a "408
> Request Time-out" response. (http://svn.haxx.se/dev/archive-2012-11
> /0076.shtml).
This was ultimately logged as a bug in the Serf project:
https://code.google.com/p/serf/issues/detail?id=91
OWNERSHIP: I can claim ownership of the ra_serf side of things if Lieven
and Ivan (or others) can step up to advise me and to cover the Serf part
itself. As for the reinstatement of Neon, I believe we need to make this
decision very soon. If we choose to reinstate, I'll claim ownership of that
task, too (post-branch).
> 4) Symmetric merge. Should be done per julianf.
Yay!
> 5) Inherited properties/Server-dictated configuration. This is marked as
> completed but I see some discussion over property names still ongoing.
This is also complete.
> 6) Conflict storage. This is marked as done but there was discussion in the
> past about needing a wc format bump? Where are we with that?
This garnered no response.
OWNERSHIP: Bert? (And is it finished for 1.8 already?)
> Beyond that we have the ordinary reviews of tests (pburba has said he's
> working on this), new apis and issue triage (cmpilato seems to have been
> doing some issue triage).
Yes, Paul has done the test review, and he and I have been sort of triaging
issues incrementally and as time allows.
> Also at the risk of opening a can of worms we need to decide on the wc
> upgrade issue? I can say that the impression I got from Subversion Live was
> that a lot of people use multiple clients and that auto-upgrade seems bad.
> But we also discussed trying to handle reads from an older wcng style wc
> without requiring a wc upgrade. Can someone drive this?
This is completed. We now require manual upgrade, per the work Stefan
Sperling did subsequent to this thread.
> In particular I'd like to see the outcome of the thread be that we have some
> idea what work we feel remains and who is going to be doing it.
We still kinda lack well-defined ownership for some of these things. See above.
> Lastly I don't want to give the impression that I'm rushing 1.8. However, I
> would like us to see us focus on the things we want to get done with 1.8.
As I indicated previously, it's one thing to "rush" a new release, and
another to do good by our users by not delaying releases indefinitely.
Of interest to me as I scanned this thread and others was the lack of new
initiatives folks are declaring as 1.8-must-haves. I believe that it's only
with a firm target in view that we'll ever be able to make the necessary
go/no-go calls that will govern what this release will ultimately look like.
So with that in mind, I'd like to suggest that we consider setting for
ourselves a goal of branching for 1.8 stabilization by the end of the
calendar year.
Thoughts? Updates to the aforementioned status reports/summaries?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: 1.8 Progress
Posted by Paul Burba <pt...@gmail.com>.
On Thu, Nov 1, 2012 at 2:42 PM, Ben Reser <be...@reser.org> wrote:
> Looking at our roadmap we have the following things still in progress:
>
> 1) local moves/renames. Based on the conversation I had on IRC this seems
> to be not done yet due to issues found in the original plan. stsp says that
> if it can't be done before we want to otherwise release 1.8 he'd like to
> pull the move code entirely. So the question here is do we wait for some
> unknown amount of time for this to complete? Is this an important 1.8
> feature?
>
> 2) Ev2. The notes say this is believed to be in a releasable state? Is
> there any work needed to verify this? Do we need to remove the use of Ev2
> in any place to avoid releasing with compatibility shims in use? Are we
> comfortable that the API is complete?
>
> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures). Plus there are
> several issues here (not all of the issues here are serf issues):
> http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&subcomponent=libsvn_ra_serf&subcomponent=libsvn_ra_neon
>
> Who can drive these issues to completion? Is there any additional testing
> work we should do to try and determine the stability of serf in light of the
> fact that we're planning to remove neon?
>
> 4) Symmetric merge. Should be done per julianf.
>
> 5) Inherited properties/Server-dictated configuration. This is marked as
> completed but I see some discussion over property names still ongoing.
I jumped the gun a bit when I merged it back to trunk. I updated the road map.
> 6) Conflict storage. This is marked as done but there was discussion in the
> past about needing a wc format bump? Where are we with that?
>
> Beyond that we have the ordinary reviews of tests (pburba has said he's
> working on this)
Summary coming shortly.
> , new apis and issue triage (cmpilato seems to have been
> doing some issue triage).
>
> Also at the risk of opening a can of worms we need to decide on the wc
> upgrade issue? I can say that the impression I got from Subversion Live was
> that a lot of people use multiple clients and that auto-upgrade seems bad.
> But we also discussed trying to handle reads from an older wcng style wc
> without requiring a wc upgrade. Can someone drive this?
>
> cmpilato started a previous thread on 1.8 progress but it got distracted
> with some other issues. A number of the same questions were outstanding
> then. So I'd appreciate if we can keep this thread focused on the issues at
> hand and not things we'd like to see in the future that aren't on the
> roadmap.
>
> In particular I'd like to see the outcome of the thread be that we have some
> idea what work we feel remains and who is going to be doing it.
>
> Lastly I don't want to give the impression that I'm rushing 1.8. However, I
> would like us to see us focus on the things we want to get done with 1.8.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: 1.8 Progress
Posted by Paul Burba <pt...@gmail.com>.
On Tue, Nov 6, 2012 at 3:37 PM, Paul Burba <pt...@gmail.com> wrote:
> On Sat, Nov 3, 2012 at 9:33 AM, Stefan Sperling <st...@elego.de> wrote:
>> On Fri, Nov 02, 2012 at 06:00:52PM -0400, Paul Burba wrote:
>>> These six XFailing upate tests are all part of this effort correct?
>>>
>>> 61 XFAIL update locally moved dir with leaf del
>>> 62 XFAIL update locally moved dir with edited leaf del
>>> 63 XFAIL update locally moved dir with incoming file
>>> 64 XFAIL update locally moved dir with incoming dir
>>
>> I believe the above date back to 1.6. They verify that tree
>> conflict detection works correctly.
>>
>> I might have changed them since 1.7 was branched to account
>> for some changes I made. I'll look into that next week.
Ping. You had any chance to take a look at these?
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: 1.8 Progress
Posted by Paul Burba <pt...@gmail.com>.
On Sat, Nov 3, 2012 at 9:33 AM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Nov 02, 2012 at 06:00:52PM -0400, Paul Burba wrote:
>> These six XFailing upate tests are all part of this effort correct?
>>
>> 61 XFAIL update locally moved dir with leaf del
>> 62 XFAIL update locally moved dir with edited leaf del
>> 63 XFAIL update locally moved dir with incoming file
>> 64 XFAIL update locally moved dir with incoming dir
>
> I believe the above date back to 1.6. They verify that tree
> conflict detection works correctly.
>
> I might have changed them since 1.7 was branched to account
> for some changes I made. I'll look into that next week.
Great, thanks!
>> 67 XFAIL text mod to moved files
>> 68 XFAIL text mod to moved file in moved dir
>>
>> If so, is there an umbrella issue we can associate them with?
>
> There is no specific issue filed for our desire to improve
> handling of tree-conflicts with local moves on update,
> though that's a goal Philip and I have in mind for 1.8.
>
> I believe from a high-level perspective these could be considered
> part of issue #3144, "interactive conflict resolution does not
> know about tree-conflicts"
> http://subversion.tigris.org/issues/show_bug.cgi?id=3144
>
> Or we could associate them with the umbrella "moves" issue:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3630
>
> Or perhaps we should re-open #3631 and associate them with that?
> http://subversion.tigris.org/issues/show_bug.cgi?id=3631
I associated #67 and #68 with both issue #3144 and issue #3630 as they
both seem to apply. The former issue is listed as 1.8-consider (the
latter is unscheduled). I'm under (the possibly mistaken) impression
that the tree-conflicts with local moves on update work isn't a
blocker for 1.8...at least not yet.
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: 1.8 Progress
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Nov 02, 2012 at 06:00:52PM -0400, Paul Burba wrote:
> These six XFailing upate tests are all part of this effort correct?
>
> 61 XFAIL update locally moved dir with leaf del
> 62 XFAIL update locally moved dir with edited leaf del
> 63 XFAIL update locally moved dir with incoming file
> 64 XFAIL update locally moved dir with incoming dir
I believe the above date back to 1.6. They verify that tree
conflict detection works correctly.
I might have changed them since 1.7 was branched to account
for some changes I made. I'll look into that next week.
> 67 XFAIL text mod to moved files
> 68 XFAIL text mod to moved file in moved dir
>
> If so, is there an umbrella issue we can associate them with?
There is no specific issue filed for our desire to improve
handling of tree-conflicts with local moves on update,
though that's a goal Philip and I have in mind for 1.8.
I believe from a high-level perspective these could be considered
part of issue #3144, "interactive conflict resolution does not
know about tree-conflicts"
http://subversion.tigris.org/issues/show_bug.cgi?id=3144
Or we could associate them with the umbrella "moves" issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=3630
Or perhaps we should re-open #3631 and associate them with that?
http://subversion.tigris.org/issues/show_bug.cgi?id=3631
Re: 1.8 Progress
Posted by Paul Burba <pt...@gmail.com>.
On Fri, Nov 2, 2012 at 11:43 AM, Philip Martin
<ph...@wandisco.com> wrote:
> Ben Reser <be...@reser.org> writes:
>
>> 1) local moves/renames. Based on the conversation I had on IRC this seems
>> to be not done yet due to issues found in the original plan. stsp says
>> that if it can't be done before we want to otherwise release 1.8 he'd like
>> to pull the move code entirely. So the question here is do we wait for
>> some unknown amount of time for this to complete? Is this an important 1.8
>> feature?
>
> I'd like to get this in. The local-move/incoming-edit stuff is not a
> huge task, I think we could get it working before the end of the year.
Hi Philip & Stefan,
These six XFailing upate tests are all part of this effort correct?
61 XFAIL update locally moved dir with leaf del
62 XFAIL update locally moved dir with edited leaf del
63 XFAIL update locally moved dir with incoming file
64 XFAIL update locally moved dir with incoming dir
67 XFAIL text mod to moved files
68 XFAIL text mod to moved file in moved dir
If so, is there an umbrella issue we can associate them with?
--
Paul T. Burba
CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development
Skype: ptburba
Re: 1.8 Progress
Posted by Philip Martin <ph...@wandisco.com>.
Ben Reser <be...@reser.org> writes:
> 1) local moves/renames. Based on the conversation I had on IRC this seems
> to be not done yet due to issues found in the original plan. stsp says
> that if it can't be done before we want to otherwise release 1.8 he'd like
> to pull the move code entirely. So the question here is do we wait for
> some unknown amount of time for this to complete? Is this an important 1.8
> feature?
I'd like to get this in. The local-move/incoming-edit stuff is not a
huge task, I think we could get it working before the end of the year.
> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures). Plus there are
> several issues here (not all of the issues here are serf issues):
> http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&subcomponent=libsvn_ra_serf&subcomponent=libsvn_ra_neon
>
> Who can drive these issues to completion? Is there any additional testing
> work we should do to try and determine the stability of serf in light of
> the fact that we're planning to remove neon?
Reinstate neon? serf has never seemed to be good enough to justify
removing neon: on the client side it is not as reliable, on the server
side the overhead in some cases is still worrying.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: 1.8 Progress
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Nov 1, 2012 at 2:42 PM, Ben Reser <be...@reser.org> wrote:
>...
> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
> that Philip has raised (EAGAIN and the random failures). Plus there are
> several issues here (not all of the issues here are serf issues):
> http://subversion.tigris.org/issues/buglist.cgi?issue_status=UNCONFIRMED&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&subcomponent=libsvn_ra_serf&subcomponent=libsvn_ra_neon
>
> Who can drive these issues to completion?
I'm going to be spending the next couple weeks in Austin. My evenings
are going to be completely free with not much to do besides hack on my
laptop (not even TV; boo!). Then a week at home, then back to Austin
for a few weeks.
I'll concentrate on reviewing the changes over the past couple months,
and then completing the work that I started in June-ish. Then close
the issues.
Cheers,
-g
Re: 1.8 Progress
Posted by Ben Reser <be...@reser.org>.
On Thu, Nov 1, 2012 at 12:00 PM, Julian Foad <ju...@btopenworld.com> wrote:
> I am not convinced the API is all finalized. Are there reasons why we need/want to release the API definition into the public name space right now? If not, I would suggest we move it into the private namespace for now, and then make it public later when we're more confident about it and have some more significant support for it in place.
>
> Does that make sense or am I missing something?
That makes sense to me.
Re: 1.8 Progress
Posted by Julian Foad <ju...@btopenworld.com>.
Ben Reser wrote:
2) Ev2. The notes say this is believed to be in a releasable state? Is there any work needed to verify this? Do we need to remove the use of Ev2 in any place to avoid releasing with compatibility shims in use? Are we comfortable that the API is complete?
I am not convinced the API is all finalized. Are there reasons why we need/want to release the API definition into the public name space right now? If not, I would suggest we move it into the private namespace for now, and then make it public later when we're more confident about it and have some more significant support for it in place.
Does that make sense or am I missing something?
- Julian