2010/11/11 Cooke, Mark <mark.co...@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
