Re: simple tree conflict detection

Stefan et al,

Any update on this tree conflict detection work?

- Julian

Erik Huelsmann wrote:
> 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.

-- 
http://www.foad.me.uk/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org