Stefan et al,
Any update on this tree conflict detection work?
Erik Huelsmann wrote:
> On Nov 21, 2007 12:12 AM, Stefan Sperling <firstname.lastname@example.org> wrote:
>>On Tue, Nov 20, 2007 at 04:30:41PM -0500, David Glasser wrote:
>>>On Nov 20, 2007 3:53 PM, Stephen Butler <email@example.com> wrote:
>>>>Quoting Erik Huelsmann <firstname.lastname@example.org>:
>>>>>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
>>>>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?
>>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
>>No one wants to add yet another huge feature before 1.5 is
> 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.email@example.com>,
>> 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
> 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
>>>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
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sun Dec 9 20:07:19 2007