You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2011/04/05 13:17:46 UTC

WC format bump: store conflict files by relpath rather than name

Text and property conflict file names are stored in ACTUAL_NODE as
simple names and the WC code has to do path manipulation to obtain the
path from name.  For the property conflict file the manipulation is
different for files and directories and this is a problem for the new
revert code as it may have removed the NODES row that contained the node
kind.

To fix this I plan to store relpaths instead of names.  There will be no
change to the SQLite tables, just to the way the existing columns are
used by the code.  I'll bump the WC format and autoupgrade existing
working copies.

-- 
Philip

Re: WC format bump: store conflict files by relpath rather than name

Posted by Philip Martin <ph...@wandisco.com>.
"C. Michael Pilato" <cm...@collab.net> writes:

>> I've got the new code working (not started on the upgrade code).  The
>> change spilled over into the public API in the form of the
>> svn_wc_conflict_description2_t structure.  This contains the names of
>> the conflict files, but it is also used within libsvn_wc as a way of
>> passing around conflict information.  It's new in 1.7 so I decided to
>> change it, it now contains abspaths rather than names.  The alternative
>> would be to introduce some other internal struct to hold the relpaths.
>
> Makes sense.  abspaths -> names is a trivial transformation anyway, yes?

Yes, one of the places it happens is svn_wc__cd2_to_cd to produce the
1.6 structure.  There is also a function svn_wc__cd_to_cd2 that goes the
other way and that is hard to do, but since the function isn't used I
simply deleted it.

-- 
Philip

Re: WC format bump: store conflict files by relpath rather than name

Posted by "C. Michael Pilato" <cm...@collab.net>.
On 04/06/2011 11:40 AM, Philip Martin wrote:
> Philip Martin <ph...@wandisco.com> writes:
> 
>> Text and property conflict file names are stored in ACTUAL_NODE as
>> simple names and the WC code has to do path manipulation to obtain the
>> path from name.  For the property conflict file the manipulation is
>> different for files and directories and this is a problem for the new
>> revert code as it may have removed the NODES row that contained the node
>> kind.
>>
>> To fix this I plan to store relpaths instead of names.  There will be no
>> change to the SQLite tables, just to the way the existing columns are
>> used by the code.  I'll bump the WC format and autoupgrade existing
>> working copies.
> 
> I've got the new code working (not started on the upgrade code).  The
> change spilled over into the public API in the form of the
> svn_wc_conflict_description2_t structure.  This contains the names of
> the conflict files, but it is also used within libsvn_wc as a way of
> passing around conflict information.  It's new in 1.7 so I decided to
> change it, it now contains abspaths rather than names.  The alternative
> would be to introduce some other internal struct to hold the relpaths.

Makes sense.  abspaths -> names is a trivial transformation anyway, yes?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand


Re: WC format bump: store conflict files by relpath rather than name

Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:

> Text and property conflict file names are stored in ACTUAL_NODE as
> simple names and the WC code has to do path manipulation to obtain the
> path from name.  For the property conflict file the manipulation is
> different for files and directories and this is a problem for the new
> revert code as it may have removed the NODES row that contained the node
> kind.
>
> To fix this I plan to store relpaths instead of names.  There will be no
> change to the SQLite tables, just to the way the existing columns are
> used by the code.  I'll bump the WC format and autoupgrade existing
> working copies.

I've got the new code working (not started on the upgrade code).  The
change spilled over into the public API in the form of the
svn_wc_conflict_description2_t structure.  This contains the names of
the conflict files, but it is also used within libsvn_wc as a way of
passing around conflict information.  It's new in 1.7 so I decided to
change it, it now contains abspaths rather than names.  The alternative
would be to introduce some other internal struct to hold the relpaths.

-- 
Philip

r1089593 bumps the WC format

Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:

> To fix this I plan to store relpaths instead of names.  There will be no
> change to the SQLite tables, just to the way the existing columns are
> used by the code.  I'll bump the WC format and autoupgrade existing
> working copies.

r1089593 bumps the WC format, using this client will autoupgrade your
working copy.

-- 
Philip

Re: WC format bump: store conflict files by relpath rather than name

Posted by Greg Stein <gs...@gmail.com>.
On Wed, Apr 6, 2011 at 08:55, Geoff Rowell <ge...@gmail.com> wrote:
> On Tue, Apr 5, 2011 at 6:56 PM, Greg Stein <gs...@gmail.com> wrote:
>> Sounds good to me.
>> On Apr 5, 2011 4:18 AM, "Philip Martin" <ph...@wandisco.com> wrote:
>>> Text and property conflict file names are stored in ACTUAL_NODE as
>>> simple names and the WC code has to do path manipulation to obtain the
>>> path from name. For the property conflict file the manipulation is
>>> different for files and directories and this is a problem for the new
>>> revert code as it may have removed the NODES row that contained the node
>>> kind.
>>>
>>> To fix this I plan to store relpaths instead of names. There will be no
>>> change to the SQLite tables, just to the way the existing columns are
>>> used by the code. I'll bump the WC format and autoupgrade existing
>>> working copies.
>
> What's the character width of that column? Doesn't that define the
> maximum relative path length?

AFAIK, SQLite does not have char widths on its columns. If it does,
then we have problems everywhere.

Cheers,
-g

Re: WC format bump: store conflict files by relpath rather than name

Posted by Geoff Rowell <ge...@gmail.com>.
On Tue, Apr 5, 2011 at 6:56 PM, Greg Stein <gs...@gmail.com> wrote:
> Sounds good to me.
> On Apr 5, 2011 4:18 AM, "Philip Martin" <ph...@wandisco.com> wrote:
>> Text and property conflict file names are stored in ACTUAL_NODE as
>> simple names and the WC code has to do path manipulation to obtain the
>> path from name. For the property conflict file the manipulation is
>> different for files and directories and this is a problem for the new
>> revert code as it may have removed the NODES row that contained the node
>> kind.
>>
>> To fix this I plan to store relpaths instead of names. There will be no
>> change to the SQLite tables, just to the way the existing columns are
>> used by the code. I'll bump the WC format and autoupgrade existing
>> working copies.

What's the character width of that column? Doesn't that define the
maximum relative path length?
-- 
Geoff Rowell
geoff.rowell@gmail.com

Re: WC format bump: store conflict files by relpath rather than name

Posted by Greg Stein <gs...@gmail.com>.
Sounds good to me.
On Apr 5, 2011 4:18 AM, "Philip Martin" <ph...@wandisco.com> wrote:
> Text and property conflict file names are stored in ACTUAL_NODE as
> simple names and the WC code has to do path manipulation to obtain the
> path from name. For the property conflict file the manipulation is
> different for files and directories and this is a problem for the new
> revert code as it may have removed the NODES row that contained the node
> kind.
>
> To fix this I plan to store relpaths instead of names. There will be no
> change to the SQLite tables, just to the way the existing columns are
> used by the code. I'll bump the WC format and autoupgrade existing
> working copies.
>
> --
> Philip