Bicking, David (HHoldings, IT) wrote:
>
>
>> 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?"
Separating 'projects' isn't an issue at all. The issue is maintaining
history that is not part of the project as you choose to view it
currently. SCM's don't make it easy for you to change history. That's
the reason you use them...
> 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.
The clean way to do this in subversion is to make all parts that can be
shared by other projects external references and to be absolutely sure
that release branches or tags that need to be reproducible in the future
peg the external references to specific revisions. I don't think there
is any easy way to migrate an old cross-linked mess into this design.
The components don't need to be in separate repositories to use
externals to reference them, but it forces the issue if they are.
> 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(?)".
Once again, history is what it is, and SCM's just maintain it even if
you wish it were something else.
> 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'd guess that most places don't migrate the whole history when things
change drastically or have become too much of a mess to fix. Instead
they keep the old SCM around just in case someone really ever wants to
revisit bugs fixed a decade ago and simply export versions at revisions
that anyone would be likely to need and commit those to the new SCM as
a clean starting point - perhaps using the 'vendor drop' approach with
some recent revisions. My own decade+ old repository was in CVS which
converts pretty cleanly and doesn't have cross-linking problems - but
you can't follow the times that someone went into the repository and
renamed, deleted, or moved things.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
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:58:10 2007