On Fri, Aug 20, 2010 at 11:55:10AM -0700, Bert Huijben wrote:
> > From: Stefan Sperling
> > - Conflict storage
> > Do we really need to have this ready for 1.7? We might as well keep
> > using the 1.6-style of "recording" conflict information in temporary
> > files, that act as conflict markers. At the very least, doing so would
> > not be a regression over 1.6, and it can be improved upon during the
> > 1.8 cycle.
> I think we need some parts of this to compensate for the new
> obstructed/missing handling. You can have a different unversioned directory
> in place where a versioned directory should be. And update can't record that
> as a conflict using just the old information.
Right. So that's one special case in the wc-ng world we simply cannot
represent with the 1.6.x conflict storage framework.
But do we really need an entirely new framework, or just a bit of
meta-data in wc.db to get this working? And drop this meta-data again
when the proper framework is in place? I guess now that we're dealing
with DB schemas rather than entries files, we can make random changes
to our meta-data easily as we go from one release to the next.
The temorary hack would just need to be supported in read-only form later.
> One of the reasons that this isn't handled, is that this upgrade can't be
> handled atomicly before we move to single-db. (Tree conflicts would move
> from the parent to the child DBs, while we only upgrade them at once. So any
> error while upgrading would break your conflict storage)
I don't think I understand what problem you're describing here.
Can you elaborate? Will there still be a problem after moving the single db?
> > - svnrdump
> > It's marked as complete, but I don't really know yet if we can consider
> it
> > complete yet. I plan to review it thoroughly again in its current state
> > before deciding whether or not I'd like to see it in 1.7. In particular,
> > the current test coverage seems quite poor, and I'm afraid of that
> hiding
> > potential problems.
> > However, if anyone already has reviewed its current state and has found
> > it to be of releasable quality, please let us know. But if noone has the
> > cycles available to review it thoroughly, and in particular to improve
> > test coverage, I'd say we should postpone it to 1.8.
>
> I think the dump part is stable.
That's good to hear!
> The load part needs more testing, but if it could load the ASF repository
> I'm happy to ship it as is and fix possible bugs later. (But I don't expect
> that this will complete now)
I'm hesitant to ship features we haven't tested.
While the impact of potential problems would be low in this case,
having users run into problems with new features always leaves a bad
impression about Subversion's quality. I'd like people to have a warm
and fuzzy feeling about storing their data in Subversion, knowing that
they can rely on Subversion and trust it with their data.
Any bugs they see, even in non-critical features, damages that trust.
> > - file externals improvements
> > Are file externals usable at all right now or are they even more broken
> > than they were in 1.6? If they aren't more broken, could we postpone
> > fixing them to 1.8?
> > At least, we should ship the feature in a state that matches the 1.6
> state.
> > It's not a killer feature that many people rely on, so I don't think
> > 1.7 should definitely wait for improvements in this area.
>
> The problem here is that we never documented how it worked in 1.6. It worked
> as a hack in 1.6 and as a slightly different hack now. Issues are
> continuously noted and more hacks are added to fix specific use cases.
But is the user experience for file externals any different after upgrading
to the current trunk code? If not, then we can just ship it as it is.
Else, we can re-design and re-implement the feature, or fix the use cases
that are broken in current trunk code, depending on which is less work.
> I'm -0 on fixing any more specific use cases until we have a proper design
> to support these file externals/internals/hacks. (I don't want to see 2
> additional if statements added to every function in libsvn_wc and
> libsvn_client, just because we never designed this feature)
If adding a couple of if-statements restores 1.6 behaviour and allows us
to ship 1.7 faster, then I'd prefer that route.
> > - svn patch
> > I'd like to really almost-feature-freeze this now (the last feature
> > freeze was before danna's Gsoc). The only feature I'd still like to
> > add is conflict recording (an exception dannas and I had in mind during
> > the pre-gsoc freeze, too).
>
> Doesn't this require the new conflict store mentioned before?
Not necessarily. We could simply treat the presence of a .svnpatch.rej
file as a conflict marker.
Stefan
Received on 2010-08-21 12:33:02 CEST