David Anderson wrote:
> [snip]
> First of all, if it wasn't clear in my initial mail and followups, I
> intend libsvn_wc_sqlite to follow the API that libsvn_wc has. There
> may be a few new functions required (for example the call to sever a
> subtree from the wc), and possibly some changes to the libsvn_wc API,
> which would have to be backwards-compatible changes. However, as
> noted, some of the semantics that some users have come to rely on
> (known location of text-bases, using .svn as the basis for knowing if
> a directory is under version control...) would be broken by
> libsvn_wc_sqlite, which is why it cannot entirely replace libsvn_wc
> before 2.0.
(Assuming this idea is being implemented with 1.x compatibility in mind.)
There will probably be a '.svn' directory, because otherwise older
clients wouldn't recognize it as a WC. Maybe only with the format file?
(In order to inform the user of his out-dated client.)
In that case this '.svn' directory could hold a file which stores the
location of the root of the WC and thus we don't need crawling. In my
view this is now allowed because the WC isn't severable anymore so the
root wouldn't change.)
> IOW, I think this is as much a compatibility break as FSFS was for BDB
> backend users, because the implicit promises that you could use BDB
> tools to mess with the filesystem went away. People have the choice
> whether or not to switch, and can make an informed decision based on
> the various tradeoffs.
Agree.
> [snip]
>
> Finally, regarding `svn edit`. After thinking about it some more, it's
> true that this feature is somewhat a separate issue to that of
> revamping the working copy.
FYI I don't like it. Seems much too administrative.
> [snip]
> However, I think that libsvn_wc_sqlite with tree crawls would still be
> a huge improvement over plain libsvn_wc, even without using an
> explicit edit operation to kill them off entirely. So, scratch
> implementing `svn edit` for now, but keep it in mind when designing.
Agree.
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 25 22:50:11 2007