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.
- Julian
---------------------------------------------------------------------
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:20:48 CEST