> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Wednesday, September 05, 2007 11:32 AM
> To: Bicking, David (HHoldings, IT)
> Cc: users@subversion.tigris.org
> Subject: Re: Copying (branch/tag), dumping, and filtering
> repository contents
>
> > No. I am evaluating various SCM packages and don't have
> the resources
> > to experiment that way, even if I did have a repository on which to
> > experiment.
>
> You don't have a computer with some disk space? Subversion
> will create a repository in your local file system that works
> just the same as server-based repositories.
As I said originally, I don't have the time or resources to make it up
and play around to figure this out. I already spent a week failing to
migrate a 10G VSS repository for tests. That time was way out of scope
for this project effort.
> > Is it unusual for people to divide large repositories into
> smaller ones?
>
> If you are worried about this, you could put each project in
> its own repository to start with and use http access which
> can make all of the URLs look the same as a single repository.
This company will not use Apache if they choose SVN, though the idea
intrests me. I'll research it.
> > That's why I am perplexed at the inability to extract
> specific paths
> > (described at the tip) and get all the information back to the
> > earliest revision, even if it was not in the tip path at
> the time it was created.
> I think the reason you didn't get any answers on this one is
> that the question doesn't make sense. If you have history in
> trunk, how can you just want to extract one branch and keep
> history which didn't exist there? Keep in mind that these
> are 'cheap' copies, not the real thing.
>
Les, I truly appreciate that you actually responded, but you are the
unfortunate recipient of my frustration, it's not personal...
*sigh* The non-answer to my question is "there is no way to do what I
ask (without hacks), and it is a stupid question in the first place".
Additionally "nobody would ever want to extract individual projects from
a repository", and the easily inferred (for the cynical like me), "what
kind of idiot would put multiple projects in one repository anyway?"
I asked the questions in an attempt to get a leg up on future planning
before a disastrous mess could form.
Sorry, but I can tell you that in my 16 years of work as a consultant in
over eight corporations, these would have been useful for maintenance.
If you and the others who feel the same way can plan your repository on
day one so that 8 years down the road, there's absolutely no reason to
make any modifications, God bless you. You are better planners than
ANYBODY I've ever seen. Consider running for President/Prime
Minister/Chancellor.
And here's my response to your questions above. The scenario I have in
mind is one in which the company in question DID NOT attempt to plan
their repository, and now have projects evolving off of each other such
that there is a huge web of copied/shared/moved files and folders. It
is impossible to isolate one piece of the puzzle for export, leaving the
other 10G of garbage behind. They cannot pull out the "Revision 4"
branch (which is all they care about going forward) because it was
branched off revision 3, which came from revision 2, etc., and they
shared a framework project into revision 1, so I can't grab any of the 4
revisions because ANOTHER project is referenced by revision 1 - which,
by the way, is corrupt. This kind of repository evolution is what I'm
trying to eliminate. To do so, I need a good plan. To plan, I need a
wide range of information and community experience, which is why I came
here.
Often, in the "Microsoft World(tm)", projects that are separate
components are frequently designed together. For example, a corporate
framework and an application that will use it. Eventually, the
framework reaches a maturity level that makes it able to stand alone and
be referenced by other projects. Unfortunately, whomever initiated this
process, put all the code (which is referenced in a single "solution")
into source control as a single project, say, "project1/" (See my FIRST
post for a clear example). Now the framework needs to be its own
"project". So these people, knowing no better, simply copy/share it to
its own location ("framework1"). Worse, rather than reference compiled
libraries of this framework, the next three projects directly reference
the source code, by sharing/copying it into their projects. Let the
hilarity begin.
Imagine this kind of process over a period of five years, with literally
dozens of different projects. One day, someone with some organizational
sense is assigned the task of cleaning up this mess (that would be ME).
Guess what? It ain't possible, in part because "the question doesn't
make sense(?)".
Those of us here on this listserv represent a minority community: those
who care about and are able to plan for source control. Have you all
only ever experienced "greenfield" SCM projects? Have none of you been
around in one place long enough to realize one day that your original
repository design doesn't make sense given the current reality? In my
experience, reality changes drastically at least every few years.
I'm not expecting constructive replies to this, I'm clearly on my own on
this particular topic, and I'll deal with that. I'm just wholly
surprised these issues are neither common, nor addressed. I've never
seen a "clean" SCM repository that I didn't build myself.
--
David
*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited. If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 5 21:09:31 2007