Sorry for the trouble, David! I'll try to provide some constructive
information:
On Sep 5, 2007, at 14:12, Bicking, David (HHoldings, IT) wrote:
>>> 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.
>
> *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'm such an idiot, for example. :) I think it's very natural to have
all projects in one repository, especially for the reasons you state
later on -- that projects evolve and turn into other projects or have
reusable frameworks branched off of them. Much easier to just "svn
cp" and "svn mv" to rearrange things within a single repository to
match whatever your current needs are, and the history is preserved,
which is nice.
I do have two repositories, in fact, but they're for things that have
nothing to do with one another -- one is for code I write, the other
is for music I compose.
Some people like putting each project into its own repository. To
each his own. There are pros and cons to each approach.
> 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.
Well, you shouldn't have any revisions that are corrupt. I know we
hear about that all the time on the list, but you should have a good
backup strategy which involves making a copy of the revision the
instant it's created, in a post-commit hook. Then back up those
copies often, to CD or DVD or tape or what have you, so that you
permanently save a good copy of the revision, so that if it ever gets
corrupted because your main disks go bad, restoring it is a quick and
painless non-issue.
> 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.
I don't have experience with compiled-library development; I only
make PHP web sites and shell scripts and such, so that the only way
to share the functionality is to share the source code. But that's
fine: with svn:externals you can pull in code from other places in
the repository, or from other repositories.
> 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(?)".
Well, the question that didn't make sense was, "If you have history
in trunk, how can you just want to extract one branch and keep
history which didn't exist there?" But I'm not sure that's the
question you asked.
I too have wondered what happens if I have, say, a library in my
repository, that originated in a different project, and now I want to
move that library to its own repository. It seems that's a difficult
task. So I probably won't embark on it; I'll probably keep everything
in one repository, because it seems nice to do so anyway.
I guess you rather asked how to archive away old projects, especially
when a library or another project has been branched off of it at some
point. And I think the answer at this point is you don't. You just
keep it in the repository. If you don't want to see that old project
in your main repository list, you can "svn mkdir $REPO_URL/old" and
"svn mv $REPO_URL/some_old_project $REPO_URL/old" to get it out of
the way, but still accessible. If your complaint is with the disk
space occupied by the old projects, then the answer from the
Subversion team is probably one of their old standards, namely that
disk space is cheap. That's not a great answer sometimes, but I can
see where they're coming from. The cost of an extra hard disk or two
is less than the cost of developing svndumpfilter further, or
implementing svnadmin obliterate, etc.
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 6 08:46:10 2007