On 11/11/2010 5:18 AM, San Martino wrote:
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.
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
lesmikes...@gmail.com
