You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Mills <dm...@enki.fr> on 2009/01/15 17:09:55 UTC
Flattening a repository.
First of all, hello to the list.
I'm currently administering a repository which is used for document
synchronisation and transfer between 2 sites.
Over the years, the size of this repository has grown to represent over
12Gb. Most of which consists of redundant change sets (deleted files
mostly).
I would like to improve this situation by flattening the repository so
that only 3-6 months of changes are kept.
My plan was to use the following command to do this:
svnadmin dump enki_old/ -r {`date --date="6 months ago" +%Y-%m-%d`}:HEAD
| svnadmin load enki
The problem is that using this command I invalidate every checkout of
the repository (I get invalid revision errors). Re-checking out will be
onerous for me as the checkouts are around 4Gb in size, and a lot of our
users are non-technical.
Is there any way for me to do this operation in a way that my users can
just update their checkouts to be in sync with the new repository?
Thank you for your time
David
--
David Mills
Enki Technologies
01 76 00 71 20
*
Lancement d'un nouveau site...
...pour Unibail-Rodamco !
*
Centre commercial Velizy 2 <http://www.velizy2.com/>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1026716
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Flattening a repository.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 15, 2009, at 11:09, David Mills wrote:
> I'm currently administering a repository which is used for document
> synchronisation and transfer between 2 sites.
>
> Over the years, the size of this repository has grown to represent
> over 12Gb. Most of which consists of redundant change sets (deleted
> files mostly).
>
> I would like to improve this situation by flattening the repository
> so that only 3-6 months of changes are kept.
>
> My plan was to use the following command to do this:
>
> svnadmin dump enki_old/ -r {`date --date="6 months ago" +%Y-%m-%
> d`}:HEAD | svnadmin load enki
>
> The problem is that using this command I invalidate every checkout
> of the repository (I get invalid revision errors). Re-checking out
> will be onerous for me as the checkouts are around 4Gb in size, and
> a lot of our users are non-technical.
>
> Is there any way for me to do this operation in a way that my users
> can just update their checkouts to be in sync with the new repository?
No, there isn't. As you've noticed, any such surgery on the
repository makes the repository a fundamentally different one,
hopefully with a totally new unique id (use "svnadmin load --ignore-
uuid" to ensure this), and new checkouts will be required.
I recommend you keep the repository as it is, with all its history,
and add server disks if necessary to keep up with the repository's
growth.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1029780
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Flattening a repository.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Jan 18, 2009, at 09:51, Karl Heinz Marbaise wrote:
>> Is there any way for me to do this operation in a way that my
>> users can
>> just update their checkouts to be in sync with the new repository?
>
> You have to use the --force-uuid in the new repository....
> But this is only the first part of the plan, cause you'll change the
> highest revision number....and that's the problem here...
Please do not use --force-uuid when the old and new repositories are
not identical! Working copies will explode in exciting ways when they
talk to the new repository and expect it to be the old repository.
That is the reason UUIDs exist -- to ensure that each unique
repository has a universally unique identifier, so that working
copies will be able to tell, via the new UUID, that they are not
talking to the same repository and must therefore abort.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1033570
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: Flattening a repository.
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi David,
> Over the years, the size of this repository has grown to represent over
> 12Gb. Most of which consists of redundant change sets (deleted files
> mostly).
>
> I would like to improve this situation by flattening the repository so
> that only 3-6 months of changes are kept.
Why would you like to remove things ? Do you have problems with the
repository ? Only 12 Gb ? I have repositories which 30-40 GB ...
>
> My plan was to use the following command to do this:
>
> svnadmin dump enki_old/ -r {`date --date="6 months ago" +%Y-%m-%d`}:HEAD
> | svnadmin load enki
>
> The problem is that using this command I invalidate every checkout of
> the repository (I get invalid revision errors). Re-checking out will be
> onerous for me as the checkouts are around 4Gb in size, and a lot of our
> users are non-technical.
If you really like to do this simply do a check via svn log and see
which revision is older than six months and remove the contents in the
dump file....
>
> Is there any way for me to do this operation in a way that my users can
> just update their checkouts to be in sync with the new repository?
You have to use the --force-uuid in the new repository....
But this is only the first part of the plan, cause you'll change the
highest revision number....and that's the problem here...
Kind regards
Karl Heinz Marbise
--
SoftwareEntwicklung Beratung Schulung Tel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl Heinz Marbaise ICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1032834
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].