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.
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. 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?
thanks
Received on 2010-11-11 12:19:24 CET