On 11/11/2010 5:18 AM, San Martino wrote:
> 2010/11/11 Cooke, Mark<mark.cooke_at_siemens.com>:
>>>>> Database/
>>>>> Scripts/
>>>>> Packages/
>>>>> Application Server
>>>>> libs/
>>>>> servlets/
>>>>>
>>>>> 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.
>
>> Did you go through an evaluation process when you selected subversion as your new tool? You must have decided that it has features you want to use? The best course of action, even if painful in the short term, is probably to use svn as it is designed rather than trying to make it fit your old working practices...
>>
>> What development tools are you using that you ended up with this repositor layout? I think a little understanding of the process that got you to where you are (and why they are now different?) might help us to help you.
>
> Thanks for your answer. In substance we have no choice, we must use
> Subversion for our new development since our new IDE is integrated
> with Subversion. We cannot change our new IDE for many reasons that
> have higher priority than Subversion. We are trying to do the best. Of
> course new projects will profit by Subversion features in a more
> evident way than before. The problem is the old stuff in the old (and
> now bad) layout controlled by PVCS previously. Since we are still in
> transition, we want to preserve as much information as possible and we
> want to control all the sources with a single tool. The new projects
> might still depend semantically on the old files which not organized
> on a "per-project" criteria. The cost of reorganizing the old layout
> is huge and not affordable.
Perhaps you can break this step into manageable chunks - like initially
importing to the old layout so old tools can find the old copies - and
make a branch copy so you can find that old layout and maintain some
backwards compatibility there for as long as you need it while the trunk
gets organized into better subdirectory groupings as you make changes.
But really 'hundreds of files' in a directory is not a big number these
days. If you aren't deleting and checking out new working copies all the
time I'm not sure you should expect a problem.
> The theoric solution we thought at the beginning to integrate the old
> stuff with the new projects is to consider the old layout and files as
> part of one big virtual project maintained under /trunk. Then we could
> starting by checking-out the root /trunk/ with "--depth empty" to a
> working local copy which is a basis when accessing the old stuff. This
> way, when needed, we just sparse-checkout single files belonging to
> the same real project (fortunately, this is automatically possible (as
> workaround) in tortoisesvn with a loop of "checkout dir --depth empty"
> until a final update of the single file). Once the changes are done we
> create a tag of the current working copy.
Theoretically you can copy a working directory to a tag. It's not
necessarily a good idea because you normally think of tags as a 'human
friendly' name for snapshot of a specific revision on the trunk or a
branch, and the stuff in your workspace may not all be committed and may
not match anything else.
> But here is the problem: the
> tag will still represent everything under /trunk and not only the
> group of files (the modified project). How are tags really "cheaps"
> (time and space on disk) when the whole /trunk is measured in Gbs of
> data? Is there really a point to tag the whole /trunk when we just
> intended to make a change to a real project?
You can basically think of anything that is copied from somewhere else
in the repository as just another name for the thing at the
location/revision that is the source of the copy. That works even if
you make the copy from your workspace - for the things that came from
the repository at least. And, if you have a checked workspace
containing the HEAD or some other revision of the whole trunk and 'svn
switch some_tag_name' only the differences should be transferred from
the repository, just the same as if you had done an 'update -r
rev_number' to the revision where the tag was made. Other than the
initial checkout time and the space on the client (2x the actual size),
having extra stuff in the wrong place may not bother you that much at all.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-11-11 20:20:19 CET