(please do not top-post on this list)
> 2010/11/10 Ryan Schmidt <subversion-2010d_at_ryandesign.com>:
> >
> > On Nov 10, 2010, at 14:09, San Martino wrote:
> >
> > > we are porting hundreds of projects from an old versioning
> > > system to subversion. We would like to make use of the trunk,
> > > tag and branch concepts. For the convertion we used an
> > > automatic tool which preserved the original layout under
> > > trunk/ . By looking at the layout, one problem is that the
> > > files of these projects are not semantically grouped into
> > > different directories (one directory for project), but are
> > > grouped according to their extensions (.txt, .dll, etc..) or
> > > software in which they are installed. For example, under
> > > trunk we have automatically obtained:
> > >
> > > 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.
> >
> > Why can't you?
> >
> > > While it will no longer be the same with the new projects (some
> > > of which might depend on old stuff), what we would like to do
> > > with the old stuff is to be able to checkout a small number of
> > > single files semantically representing a project and tag the
> > > release or snapshot under /tag when the changes are done.
> > >
> > > How could we do in your opinion?
> >
> > You could check out the large directory.
> >
> > Or you could check out a sparse directory of only what you
> > need to work on.
> >
> > Or you could reorganize the files by project so that you
> > can check out each project. If there are hundreds of projects
> > and this is daunting, you could just convert projects as you
> > need to work on them.
> >
> >
> -----Original Message-----
> From: San Martino [mailto:sanmrtn96_at_gmail.com]
> Sent: 10 November 2010 21:05
> Subject: Re: Help or suggestions on porting to subversion
>
> Hello Ryan,
>
> Of course the cleanest way is to checkout the whole trunk/ and tag the
> trunk each time.
> A single checkout of the whole / directory is tens of GB over a
> network (non-LAN), multiply this for all the deveopers.
> The solution does not scale well even if checkout with --depth is
> disabled. Furthermore tagging the whole trunk each time would be make
> the concept it is for pointless.
>
...however, the full checkout is only done once (per developer) and then only updates are transferred. This is probably not as big a problem as you may think. Also, if the developers are co-located you can probably copy a single fresh WC between developers within your own network (before anyone messes with the virgin WC).
> The thing we want is:
> - checkout single/scattered files from different directories
> - modify/commit them
> - group the files and tag this group (only the files in this group).
>
This is not AFAIK directly possible in subversion (or any other similar tool that I have used). You could try using file externals in a new project directory but I have not used them and believe there are "issues".
> The slow transition of reorganizing by moving the files in projects as
> we modify them is basically not possible and might be confusing. Also
> not every developer has an idea of all the dependencies involved when
> he/she just wants to modify a single file. It's even possible that
> base/common libraries will never be touched at all. Just Tto be short
> there are other reasons I will not mention ..
>
I do not know your project but when we converted from another SCCS product, we decided to import the complete tree as-was into one repo (so the history was available) but then made that read-only and started new, fresh repos for related projects with sensible layouts.
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.
Good luck,
~ mark c
Received on 2010-11-11 09:06:25 CET