On Thu, Nov 11, 2010 at 12:18 PM, San Martino <sanmrtn96_at_gmail.com> 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.
> 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?
I think you can also make a tag or branch of a subset of files
completely on the server (without the need to create a sparse working
copy first). This can be done with the --parents option of "svn copy",
and multiple SRC arguments (which can all be url's):
svn copy --parents
https://svn.example.com/trunk/dirwithmanyfiles/file1
https://svn.example.com/trunk/dirwithmanyfiles/file2
https://svn.example.com/branches/mybranch/dirwithmanyfiles
(all on one line, i.e. one command). Or same with tags instead of branches.
I'm not sure how that works out with merging, but maybe you don't need
merge (tracking) anyway ... YMMV.
Cheers,
--
Johan
Received on 2010-11-11 21:56:03 CET