[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Updatable svn export

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 9 Jul 2013 18:04:13 +0200

> -----Original Message-----
> From: Markus Schaber [mailto:m.schaber_at_codesys.com]
> Sent: dinsdag 9 juli 2013 17:09
> To: Daniel Shahaf; David Schweikert
> Cc: dev_at_subversion.apache.org
> Subject: AW: Updatable svn export
>
> Hi,
>
> Von: Daniel Shahaf [mailto:danielsh_at_elego.de]
>
> > David Schweikert wrote on Thu, Jul 04, 2013 at 15:04:34 +0200:
> > > I was thinking that we could use something like a "svn update
> > > --readonly", where svn doesn't any check anything on the working copy,
> > > but just applies any changes committed since the last update.
> >
> > That's a common scenario, for example it applies to:
> >
> > http://subversion.apache.org/faq.html#website-auto-update
> > https://svn.apache.org/repos/asf/subversion/trunk/tools/server-
> > side/svnpubsub/svnwcsub.py
> >
> > so enhnacing the core to support it better is not a bad idea.[1] I'm
not
> > sure whether specifically svn update --do-not-crawl-the-disk is the best
> way
> > forward; Johan's suggestion of a broader users@ discussion might lead to
> > identifying a better solution.
>
> Is it really always crawling the whole working copy? It could do so later,
> and just for the nodes which were actually touched by the update.

As part of the update we report which version of which nodes exist in the
working copy. Ideally the working copy contains a single revision and no
switched paths, in which case there is not much to report, but in other
cases this report can get bigger.

Without this report the server can't 'minimally describe' the changes
needed.

And getting a full checkout would be much slower than a local crawl (which
is just reading wc.db, plus in many cases a local exists check to restore
missing nodes).

        Bert
Received on 2013-07-09 18:05:18 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.