Of course the cleanest way is to checkout the whole trunk/ and tag the
trunk each time.
A single checkout of the whole / directory is tens of GB over a
network (non-LAN), multiply this for all the deveopers.
The solution does not scale well even if checkout with --depth is
disabled. Furthermore tagging the whole trunk each time would be make
the concept it is for pointless.
The thing we want is:
- checkout single/scattered files from different directories
- modify/commit them
- group the files and tag this group (only the files in this group).
The slow transition of reorganizing by moving the files in projects as
we modify them is basically not possible and might be confusing. Also
not every developer has an idea of all the dependencies involved when
he/she just wants to modify a single file. It's even possible that
base/common libraries will never be touched at all. Just Tto be short
there are other reasons I will not mention ..
2010/11/10 Ryan Schmidt <subversion-2010d_at_ryandesign.com>:
> On Nov 10, 2010, at 14:09, San Martino wrote:
>> we are porting hundreds of projects from an old versioning system to
>> subversion. We would like to make use of the trunk, tag and branch
>> For the convertion we used an automatic tool which preserved the
>> original layout under trunk/ . By looking at the layout, one problem
>> is that the files of these projects are not semantically grouped into
>> different directories (one directory for project), but are grouped
>> according to their extensions (.txt, .dll, etc..) or software in which
>> they are installed. For example, under trunk we have automatically
>> Application Server
>> while /tag and branch/ are empty
>> There are hundreds of files under each directory. We want to preserve
>> this layout, since it's basically impossible to reorganize all the
>> files in projects/directories.
>> Furthermore, we cannot checkout/update these huge directories whenever
>> we want to change a single file, for example a single package.
> Why can't you?
>> While it will no longer be the same with the new projects (some of
>> which might depend on old stuff), what we would like to do with the
>> old stuff is to be able to checkout a small number of single files
>> semantically representing a project and tag the release or snapshot
>> under /tag when the changes are done.
>> How could we do in your opinion?
> You could check out the large directory.
> Or you could check out a sparse directory of only what you need to work on.
> Or you could reorganize the files by project so that you can check out each project. If there are hundreds of projects and this is daunting, you could just convert projects as you need to work on them.
Received on 2010-11-10 22:06:01 CET