Julian Foad wrote:
> On Mon, 2008-09-15 at 17:57 +0100, Julian Foad wrote:
>> On Mon, 2008-09-15 at 17:46 +0100, Julian Foad wrote:
>>> On Mon, 2008-09-15 at 12:30 -0400, Mark Phippard wrote:
>>>> On Mon, Sep 15, 2008 at 12:27 PM, Julian Foad
>>>> <julianfoad_at_btopenworld.com> wrote:
>>>>> I am merging the tree-conflicts branch to trunk today. This is by no
>>>>> means "finished". Some tree-conflict behaviour is not yet done or not
>>>>> yet as we want it. The merge is to facilitate further work in this area.
>>>> For those that work off trunk builds ... I am assuming that the WC
>>>> format is now bumped due to the new tree-conflict values in entries?
>>> Oh... no. The format of the entries file is changed, but there is no
>>> code to change or use a new format number. Sorry - I remember you
>>> mentioned this a long time ago.
>>>
>>> As I understand it, a format number "bump" is required if we're changing
>>> the format. Therefore we have to implement this before merging to trunk,
>>> otherwise existing working copies will be broken. Is that right? (Given
>>> that I can tell you that the code just writes and reads an extra field,
>>> with no special magic to attempt to make it backward compatible.)
>> In 'subversion/libsvn_wc/README' it says:
>>
>> "Empty fields that are only followed by empty fields may be omited from
>> the record."
>>
>> That should mean that the tree-conflicts branch could read an existing
>> WC perfectly. However, this format description doesn't say anything
>> about compatibility in the other direction.
>>
>> I'm looking at the code now to see what I think will happen, and will
>> try some experiments too.
>
> The code (both trunk and tree-conflicts branch) appears to avoid writing
> an extra field if the extra field is empty, and tolerates an extra field
> on reading. This should mean that, as long as there are no tree
> conflicts recorded in the WC, the WC is compatible.
>
> Experiment reveals that a trunk svn can read the entries written by
> tree-conflicts branch. When showing the status of a tree-conflicts WC
> that actually has tree conflicts in it, a trunk build simply does not
> show any tree-conflict status, but successfully shows the rest of the
> status. When a trunk build rewrites such an entries file, it wipes out
> the tree-conflict information, and a tree-conflicts build simply thinks
> there are no longer any tree conflicts.
>
> This seems to be compatible enough to go ahead without bumping the
> format number yet. We need to bump the format number before releasing
> this feature. I will file an issue now to remember this.
The file externals work is bumping the wc format number. Here's how I did it in
r31758.
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-15 19:57:55 CEST