Re: simple tree conflict detection

[Julian Foad <ju...@btopenworld.com>]

Stefan et al,

Any update on this tree conflict detection work?

- Julian


Erik Huelsmann wrote:
> On Nov 21, 2007 12:12 AM, Stefan Sperling <st...@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 <sb...@elego.de> wrote:
>>>
>>>>Quoting Erik Huelsmann <eh...@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 <47...@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.


-- 
http://www.foad.me.uk/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: simple tree conflict detection

[Julian Foad <ju...@btopenworld.com>]

Julian Foad wrote:
> Stefan et al,
> 
> Any update on this tree conflict detection work?

I spoke too soon... I have just seen your "[PATCH] please review: kicking off 
the tree-conflicts branch" which I will try to review, and your comment in it 
that you will be out of action for a week or more. I hope you are comfortable.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org