> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2007b@ryandesign.com]
> Sent: Thursday, September 06, 2007 2:48 AM
> To: Bicking, David (HHoldings, IT)
> Cc: users@subversion.tigris.org; lesmikesell@gmail.com
> Subject: Re: Copying (branch/tag), dumping, and filtering
> repository contents
>
> 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:
>
--- snip ---
> > *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.
This is precisely what is necessary in a dynamic environment, but you
then lose the ability to extract discrete projects.
>
> 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.
Exactly! I want to know the best practices of each approach.
--- snip ---
> > 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.
I totally agree. In this case, it is a VSS repository, so it comes with
the territory.
--- snip ---
> 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.
I examined svn:externals, and think it might be useful, but it has
caveats and I'm unsure if it has any side effects.
--- snip ---
>
> 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.
It appears to be impossible in SVN. The most likely scenario for
extracting one particular branch, all the way to the root, is when one
wants or needs to pull out the important information and discard the
chaff. The most likely situation in which this scenario will rear its
ugly head is when some poor schmuck like me comes in and realizes that
the repository was not planned, monitored, or otherwise controlled for
the previous X years. Secondary to that, is the "mistakes were made"
scenario, or "well, I didn't expect THAT business process change when I
set things up 3 years ago!".
>
> 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.
I can deal with that, if I know that's my only reasonable option. I
still don't like it. One potential problematic scenario is that one
might have 10 projects, two of which are currently heavily active.
There may well be a need and desire to keep all 10 projects in the
repository, but the two active projects are so active that it becomes
necessary to archive revisions prior to 6 months ago. Would the
dump/load process eliminate the other 8 projects because they were last
revised 8 months ago, or would there be a single, full revision of them
left 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
Those of us who work in corporate environments have to battle reality.
We have a situation now where the VSS repository is 10G, and we can't
get new disk space allocated. There are processes, procedures,
governances, etc. Eventually it will happen, but in the mean time
considerably more money will likely be spent dealing with the problem
than would have been spent with a quick upgrade. Sometimes, the
complexity of the environment can make a simple volume increase a
difficult proposition, I suppose.
> 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.
It's less financially, not necessarily so in business process reality.
Thank you for your reply.
*************************************************************************
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 Fri Sep 7 18:56:54 2007