On Mon, Jun 25, 2012 at 6:23 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Mon, Jun 25, 2012 at 11:53 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Jun 25, 2012, at 3:14 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>...
>>> I don't see a way to avoid this problem for 1.7 clients, apart from either
>>> reverting the tree conflict description changes or bumping the format.
Right. Or find some other way to represent the information.
>> What about the move feature? What happens when 1.7 client commits a move or partial move that was made with 1.8?
If 1.8 performs the move, then you have two options:
A) the WC remains at 1.7 format, so the "new-style move" is not
performed. 1.7 can commit.
B) the WC is on 1.8 format, so 1.7 cannot work with the WC at all
> Agreed, that was a bad idea.
>
> But "the other way around", where a 1.8 client carries around 1.7
> compatibility code to keep working with 1.7-format working copies
> (upgrade being optional (to enable local-move-tracking for instance))
> is still a sensible idea I think. Although it would definitely be a
> lot of work, there is no argument there ...
Historically, whenever we have changed the format, then the working
copy is auto-upgraded the first time we (re)wrote the .svn/entries
file. The upgrade was invisible and fast, so it Just Happened. At that
moment, older versions of Subversion could no longer use the working
copy.
The 1.7 upgrade was considered too time-consuming and invasive to
continue with the auto-upgrade mechanism. We required people to
manually upgrade the working copy.
Today, we carry around the working copy's format in one of the wc_db
structures. We also have flags for performing upgrades. It should not
be too hard for the code to work with multiple formats.
However: we don't have a good concept of "read-only vs read-write"
operations at the wc_db level, like we used to have with the entries
file. As soon as we touch a working copy (eg. "svn info" or "svn
status"), then we would likely perform the auto-upgrade. We might need
some decent tooling to go back to the "only upgrade when writing"
model. For example, maybe when an administrative lock is constructed,
then we check for an old format and perform the auto-upgrade before
continuing the (modifying) operation.
If you look at libsvn_wc/wc.h, then you'll see the history of when we
bumped the format:
1.0 thru 1.3 used the same format. Then we bumped in each of 1.4, 1.5,
1.6, and 1.7.
Cheers,
-g
Received on 2012-06-26 01:52:32 CEST