> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: zaterdag 21 augustus 2010 3:32
> To: Bert Huijben
> Cc: dev_at_subversion.apache.org
> Subject: Re: Reduce the 1.7 release feature set a bit?
>
> 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.
The entire framework is the adding of the data in the db. If you start doing
some details it is not necessary harder to do the rest at the same time
> > 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?
Currently we take one entries file.. and turn that in one wc.db. If
something fails we delete the wc.db and leave the entries file in place.
The problem with tree conflicts on directories is that the conflict is
stored in the parents wc.db, while in the new schema it belongs in the
child.
If you say the upgrade succeeded on the parent, the data is no longer in the
parent wc.db. But the child is not updated yet, so the data is not in the
child. It's just in memory at that time.
With single-db we can have a transaction over the data move (or we move all
data at once) and in both cases you can roll back.
> > > - 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.
Well... since 1.6.0 some developers have tried to fix 'some' user issues..
and added if's here and there.
And then another issue was found.. adding more ifs
And before we get to 1.7 we add hundreds of more ifs to support an
undersigned feature.
And we can't say that it was similar to 1.6, because it was never designed.
It probabably is: It's still an ugly hack without documentation.
But the hack gets bigger and bigger, and if it continuous this way we can
talk about wc-ng-ng in two years, instead of in twenty years.
> > 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.
What is 1.6 behavior?
And what about adding 2000 if statements?
Without a design you don't know how many if's you need and there are at
least more than a few in the current code and file external interaction with
other features is virtually untested by our test suite. So this would
probably require many more.
Summary: NEEDS-DESIGN before adding more ifs.
>
> > > - 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.
-1
This would slow down every status walk by statting that file suffix for
every file, because we didn't store it in the DB and getting the information
directly.
(And we would have to do that in all future versions to keep compatibility
with users removing that file to resolve the conflict)
I would rather drop the entire patch support for 1.7 then going that way.
(wc-ng-ng tomorrow?)
Bert
Received on 2010-08-21 18:19:10 CEST