[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Dump and Reload question

From: Talden <talden_at_gmail.com>
Date: 2007-09-18 23:10:34 CEST

As I understand it you can

For each old repo
1. Dump the old repo (make a note of the revision) and load the dump
into the new repo with the same UUID.
2. Close off the old repo (prevent new commits)
3. Incrementally dump any commits added to old repo, since the
revision you recorded in step 1, and load the incremental dump into
the new repo.
4. Make the new repo available under the same URL as the old repo.

My understanding is that this gives the new repo the same identity as
the old and would make the 'repo' (new or old, it doesn't matter from
the users point of view) unavailable for use for the least amount of
time.

Since I'm about to be administering Subversion repositories myself,
I'd like someone here with more experience to confirm this procedure
is correct (or correct me of course ;-))

--
Talden
On 9/19/07, Troy Bull <TBull@ifmc.org> wrote:
> Greetings
>
> We have many repositories.  If I upgrade the server, then dump and reload each repository with the new version, will peoples working copies still "work"?  It will be impossible for me to get everyone to check everything in without a HUGE amount of work, so the situation I worry about is as follows:
>
> User has a "dirty" working copy
> I upgrade the server and dump and reload
> User comes to work Monday morning and tries to commit.
>
> That last commit (line 3) needs to work for me to be successful.  We are currently 1.2.3 (I think), and I was thinking I would hold off on this upgrade until 1.5 comes out next spring.
>
> Thanks in Advance
>
> Troy
>
>
>
>
>
> "CONFIDENTIALITY NOTICE: This communication, including any attachments, may contain confidential information and is intended only for the individual or entity to whom it is addressed.  Any review, dissemination, or copying of this communication by anyone other than the intended recipient is strictly prohibited.  If you are not the intended recipient, please contact the sender by reply email and delete and destroy all copies of the original message."
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 18 23:10:54 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.