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


From: Radomir Zoltowski <Radomir.Zoltowski_at_s3group.com>
Date: Tue, 16 Feb 2010 11:58:30 +0000


I am reading WC-NG design from
http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/design. I
expect deployment of 1.7.x in my environment mid this year, therefore, I
would ask a few questions here. This is purely administrative approach,
which by some may be considered simplistic, minimalist or even
conservative. Nevertheless, can I?


    According to the user's config, the metadata will be placed in one of
    three areas:

         wcroot: at the root of the working copy in a .svn subdirectory
         home: in the .subversion/wc/ subdirectory
         /some/path: stored in the given path

What will be the default location for meta-data directory? How one tells
that a specific location on a disk is a part of working copy when .svn
directiory is relocated?


    If the user has moved the wcroot (the stored path
    is different from the current/actual path), then Subversion will exit
    with an error. The user must then ###somehow tell svn that the wc has
    been copied (duplicate the metadata for the wcroot) or moved (tweak
    the path stored in the metadata and in the linkage file).

It should be understood here, that large repositories in some
(enterprise) environments are very resource expensive to be checked out
multiple times to all users of the repository. Working copies should
still work on a "check-out-once copy-everywhere" deployment model. I
would say, that not everything about CVS (or even RCS) was bad.
Nevertheless, if the above was implemented as described, would it be
possible to reset meta-data (without full binary check-out) to a new
location of working-copy? Naturally, it would probably land in extended
'svn cleanup' with perhaps already known '--relocate' option, but I am
leaving it as an open suggestion. Also, I am assuming that one extra
step can be accepted by most administrators and users, which may not be
the case initially.

... or putting things differently. Let's say, there is a team of 100
people somewhere in Europe awaiting an access to a 250 GB repository
somewhere in Australia. What to do to avoid 100 check-outs? Assume the
repository contains binary data and must be checked out in full. Slave
with http-based proxy is not an option (until svn+ssh-based proxy is


    absent<none> Server has marked the node as "absent",
                                   meaning the user does not have
                                   authorization to view the content.

Is there a plan to make server aware of it's working copies,
specifically nodes in this case? If yes, what is it going to solve? I am
seeing extra management tasks and points of failures here. Please
correct me if I am wrong.

    All metadata will be stored into a single SQLite database. This
    includes all of the "entry" fields *and* all of the properties
    attached to the files/directories. SQLite transactions will be used
    rather than the "loggy" mechanics of wc-1.0.

What is SQLite going to solve? If metadata is in one location, it is
assumed that amount of data stored will be significantly reduced. Can
anybody explain the rationale for using SQLite here, please? Again, from
my perspective, it is another layer which brings another point of failure.

Kind regards,

The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications_at_s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
Received on 2010-02-16 12:59:09 CET

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

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