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

Re: Question about performance and space

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Fri, 12 Nov 2010 15:00:19 +0100

Hi San,

On Fri, Nov 12, 2010 at 2:57 PM, San Martino <sanmrtn96_at_gmail.com> wrote:
> 2010/11/11 Les Mikesell <lesmikesell_at_gmail.com>:
>> That's not wrong in the sense that it won't work for a small repository, but
>> it is not an efficient way to use subversion where you are concerned about
>> space or time usage on the client.  Normally you would just check out
>> workspaces of one or more locations where you intend to work and if you
>> branch or tag, switch an existing workspace to it (to make changes in a
>> branch or build from the tag, which by convention should not have subsequent
>> changes).  Just be sure you have committed anything that belongs in the
>> current location before the switch. If checkout time is an issue you can
>> copy an existing local workspace as the starting point for a subsequent
>> switch.
> Do you think Subversion scales well for the following case, where
> /trunk contains about 5000 files and its size is 500Mb
> development requires 10 commits per day, 2-3 files changed per commit
> on average.
> Each commit is tagged (yes) from /trunk on the repository. How we will
> test the tag is a separate issue.

Why would you want to tag each commit? A commit is a tag in itself:
there's a unique identifier to refer to the entire commit. This wasn't
the case in PVCS, RCS and CVS, but there's really no reason to tag
each and every commit; if you want to check out what got committed,
just use the revision number!

> For now also suppose the local wc only contains sparse-checkouts of
> single files, not the whole /trunk.
> Also suppose that a reorganization of /trunk is not possible.


Received on 2010-11-12 15:01: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.