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.
Bye,
Erik.
Received on 2010-11-12 15:01:09 CET