On Nov 21, 2007 12:12 AM, Stefan Sperling <stsp@elego.de> wrote:
> On Tue, Nov 20, 2007 at 04:30:41PM -0500, David Glasser wrote:
> > On Nov 20, 2007 3:53 PM, Stephen Butler <sbutler@elego.de> wrote:
> > > Quoting Erik Huelsmann <ehuels@gmail.com>:
> > > >
> > > > Since we already have a wc-version bump on our hands, I'd like to
> > > > suggest we change the on-disk entries structure where required to make
> > > > our life as simple as possible. This is -in libsvn_wc- already hard
> > > > enough.
> > > >
> > > Is there a version bump imminent for other reasons than tree-conflicts?
> >
> > There is a version bump in version 1.5.
>
> Does adding a new wcprop imply a working copy format version bump?
No.
> Looking at the comments in libsvn_wc/wc.h that talk about version
> bumps, it seems as if it didn't.
That's correct :-)
> > However, I can't imagine how
> > that is relevant to the tree conflicts feature, since I can't imagine
> > that yet another big feature is going to get into 1.5 before we
> > branch...
>
> No one wants to add yet another huge feature before 1.5 is
> branched.
Right. Lets not put it this way. You start creating the feature on a
branch. Then, when the feature is done, we'll see where we stand. If
1.5 has been branched and the feature isn't backward compatible, then
we'll have to wait releasing it until 1.6 or speed up a 1.6 release
(my personal favorite). In the mean time this specific customer can
have a version of the code which is not forward compatible with the
mainline, but API compatible with 1.5 or whatever way is most
appropriate for them.
> Michael Pilato phrased it well in <47432D47.6060400@collab.net>,
> quote:
>
> Since the situation is arguably a bug (and therefore a candidate
> for resolution in a patch release), if a solution can be provided
> in a patch release while obeying our API compatability constraints,
> then on the assumption that 1.5.x will be released before 1.6.0,
> it makes for a good thing to target.
> So ideally, we'd like to have a place to store tree conflict information
> that is backwards-compatible and does not require wc format changes.
> It looks like wcprops were suitable -- is this assumption correct?
Well, there are 2 ways to make sure this bug can be fixed in 1.5.x:
either delay 1.5 (if it needs further delaying) and integrate the
complete feature or integrate required api changes but not the fix in
1.5.0 and release the fix after thorough testing (and start using the
.svn/entries changes). The latter isn't really what we do in his
project.
Unfortunately, even though there is little practical difference
between wcprops and the entries file, there is a large functional
difference which makes wcprops inappropriate to store directory
conflicts: wcprops are for storing working copy related RA layer
'variables'. Currently only ra_neon/ra_serf use it to store the
version URL which corresponds with every element in the working copy.
Storing state data about the working copy itself is restricted to
.svn/entries...
> > The choice between wcprops and entry fields should be made based on
> > which is more appropriate for the feature, not version bump reasons.
>
> I don't really see a functional difference between using a wcprop
> or a field in .svn/entries to store tree conflict information for
> a directory. From a functional point of view, both just store a byte
> string, it's just that the API to access either is different.
Right, that's when you look strictly at the API, but if you look at
the larger design (I'm not saying I know where that picture is stored,
so, I'm not sure how you could do that...) you'll see they have very
differing functions/goals.
For the long term solution I'd like to keep the fix for tree conflicts
as close to the original intentions of the libsvn_wc structure
(meaning that I'd like to admin wc status in .svn/entries if at all
possible).
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 21 13:40:35 2007