On 1/25/07, Danny van Heumen <danny.vanheumen@hccnet.nl> wrote:
>
> 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.
The tree crawl (if needed) would be rather easy going upward as it is only
one direction looking for one file. (Not that we want to do any more than
needed) Relative to TSVN, this is much less than the downward crawl it
needs to do looking at multiple branches at each level.
(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.)
While I agree that the .svn directories should still be there and contain at
least some format and linkage information, I have a problem with the
statement that the root would not change.
If the linkage information is relative to the .svn directory it is in, then
yes, I agree with this statement.
However, if the linkage information is an absolute path, then I strongly
disagree. I many times end up having things be renamed (moved) from one
location to another. And in networked environments, what is
/home/mks/project on one machine may be /nfs/fox/mks/project on another.
(While I like and very much has used the current severability of the WC, I
also really want server-controlled configuration and inherited properties,
both of which end up acting against severability.)
> > [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.
>
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:Michael.Sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
Received on Fri Jan 26 17:14:19 2007