Login | Register
My pages Projects Community openCollabNet

Discussions > users [DISABLED] > Resizing an existing repository while keeping the revision numbering

subversion
Discussion topic

Hide all messages in topic

All messages in topic

Re: Resizing an existing repository while keeping the revision numbering

Author TH Lim <sshark at gmail dot com>
Full name TH Lim <sshark at gmail dot com>
Date 2009-08-11 03:08:46 PDT
Message You are right. I am just confusing myself and the system if I go ahead with
this. Let me rethink this over.
Thanks

/lim/


Ryan Schmidt-60 wrote:
>
> On Aug 11, 2009, at 04:14, TH Lim wrote:
>
>> I totally understand "Subversion is to retain all your history".
>>
>> To elaborate, say, I have 100 revisions. I find tat i don't need
>> revisions
>> 0:90. So from tomorrow onwards I want to keep revisions 91 to 100.
>> I could
>> do that by dumping 91:100 and load into a new repository. Doing so,
>> reset my
>> revision number to 1. Basically, I do not want to upset the
>> revision number
>> in my local workspace which is clocked at revision 100. I don't
>> know if this
>> is a good idea to retain the revision.
>
> I understand what you're saying, but Subversion is not designed to
> work like that. Even if you keep the same revision numbers, if each
> revision is not identical in the new repository to what it was in the
> old repository (which it won't be for those empty revisions you'd
> have to create at the beginning to keep your later revision numbers
> the same), then it is not the same repository as before, therefore
> you have to assign it a new UUID, therefore you have to discard all
> working copies and check out new ones.
>
> --------------------​--------------------​--------------
> http://subversion.ti​gris.org/ds/viewMess​age.do?dsForumId=106​5&dsMessageId=23​82401
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@s​ubversion.tigris.org​].
>
>

--
View this message in context: http://www.nabble.co​m/Resizing-an-existi​ng-repository-while-​keeping-the-revision​-numbering-tp2460305​7p24914844.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: Resizing an existing repository while keeping the revision numbering

Author ryandesign
Full name Ryan Schmidt
Date 2009-08-11 02:58:48 PDT
Message On Aug 11, 2009, at 04:14, TH Lim wrote:

> I totally understand "Subversion is to retain all your history".
>
> To elaborate, say, I have 100 revisions. I find tat i don't need
> revisions
> 0:90. So from tomorrow onwards I want to keep revisions 91 to 100.
> I could
> do that by dumping 91:100 and load into a new repository. Doing so,
> reset my
> revision number to 1. Basically, I do not want to upset the
> revision number
> in my local workspace which is clocked at revision 100. I don't
> know if this
> is a good idea to retain the revision.

I understand what you're saying, but Subversion is not designed to
work like that. Even if you keep the same revision numbers, if each
revision is not identical in the new repository to what it was in the
old repository (which it won't be for those empty revisions you'd
have to create at the beginning to keep your later revision numbers
the same), then it is not the same repository as before, therefore
you have to assign it a new UUID, therefore you have to discard all
working copies and check out new ones.

Re: Resizing an existing repository while keeping the revision numbering

Author TH Lim <sshark at gmail dot com>
Full name TH Lim <sshark at gmail dot com>
Date 2009-08-11 02:15:15 PDT
Message I totally understand "Subversion is to retain all your history".

To elaborate, say, I have 100 revisions. I find tat i don't need revisions
0:90. So from tomorrow onwards I want to keep revisions 91 to 100. I could
do that by dumping 91:100 and load into a new repository. Doing so, reset my
revision number to 1. Basically, I do not want to upset the revision number
in my local workspace which is clocked at revision 100. I don't know if this
is a good idea to retain the revision.


Ryan Schmidt-60 wrote:
>
> On Aug 11, 2009, at 01:31, TH Lim wrote:
>
>> Does the local workspace able to check into the resized repository
>> with the
>> dummy inserts with checking out?
>>
>> I want to keep my repository in a "sizable size" for ease of backup
>> and
>> holding about a 100 or less revisions at any 1 time is workable for
>> me.
>
> I'm not entirely clear about your question, but Subversion is
> designed to retain all your history, so getting it to forget some of
> it later is difficult.
>
> --------------------​--------------------​--------------
> http://subversion.ti​gris.org/ds/viewMess​age.do?dsForumId=106​5&dsMessageId=23​82384
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@s​ubversion.tigris.org​].
>
>

--
View this message in context: http://www.nabble.co​m/Resizing-an-existi​ng-repository-while-​keeping-the-revision​-numbering-tp2460305​7p24914240.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: Resizing an existing repository while keeping the revision numbering

Author ryandesign
Full name Ryan Schmidt
Date 2009-08-11 02:02:16 PDT
Message On Aug 11, 2009, at 01:31, TH Lim wrote:

> Does the local workspace able to check into the resized repository
> with the
> dummy inserts with checking out?
>
> I want to keep my repository in a "sizable size" for ease of backup
> and
> holding about a 100 or less revisions at any 1 time is workable for
> me.

I'm not entirely clear about your question, but Subversion is
designed to retain all your history, so getting it to forget some of
it later is difficult.

RE: Resizing an existing repository while keeping the revision numbering

Author TH Lim <sshark at gmail dot com>
Full name TH Lim <sshark at gmail dot com>
Date 2009-08-10 23:31:18 PDT
Message Does the local workspace able to check into the resized repository with the
dummy inserts with checking out?

I want to keep my repository in a "sizable size" for ease of backup and
holding about a 100 or less revisions at any 1 time is workable for me.

Thanks

/lim/


Oleg X Rasskazov wrote:
>
> As it happens, subversion is really efficient with storing binary deltas,
> especially if you are talking
> about builds of two nearby revisions for a library. It is very useful for
> regression testing, especially if you can not run all of the tests for
> each committed revision due to compute constraints.
>
> Question though remains. Is it possible to add a flag to the svn load
> saying "start loading dump from revision nnnn?"
> If that does not fit the design of subversion, what about a flag to
> svnadmin "put n empty(trivial change) revisions on top of the current
> repo?"
>
> Doing svn ci of a dummy file via Perl script takes too long (about
> 2-3hours for 20k dummy revisions on my box).
>
> A usage scenario is when you would like to have a mirror for all the
> revisions from now on, and do not bother with doing a 2-3 day sync over a
> slow connection for the whole repo.
>
> best regards,
> Oleg
>
> -----Original Message-----
> From: Andy Levy [mailto:andy dot levy at gmail dot com]
> Sent: 22 July 2009 14:03
> To: Andrey Repin
> Cc: Oleg X Rasskazov
> Subject: Re: Resizing an existing repository while keeping the revision
> numbering
>
> On Wed, Jul 22, 2009 at 08:55, Andrey Repin<anrdaemon@f​reemail.ru> wrote:
>> Greetings, Oleg X Rasskazov!
>>
>>> One of the ways we use subversion is to store compiled binaries of all
>>> the
>>> revisions of a large library we are working on. Even with efficient
>>> subversion storage algorithms (deltifying changes) and cheap hdds we are
>>> running out of space.
>>
>> As far as I know, SVN deltify only text/* files.
>
> Subversion performs a binary diff algorithm on all files for storage.
> If the files/diffs are sufficiently large, then a completely new copy
> will be stored.
> This email is confidential and subject to important disclaimers and
> conditions including on offers for the purchase or sale of
> securities, accuracy and completeness of information, viruses,
> confidentiality, legal privilege, and legal entity disclaimers,
> available at http://www.jpmorgan.​com/pages/disclosure​s/email.
>
> --------------------​--------------------​--------------
> http://subversion.ti​gris.org/ds/viewMess​age.do?dsForumId=106​5&dsMessageId=23​74490
>
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@s​ubversion.tigris.org​].
>
>

--
View this message in context: http://www.nabble.co​m/Resizing-an-existi​ng-repository-while-​keeping-the-revision​-numbering-tp2460305​7p24912364.html
Sent from the Subversion Users mailing list archive at Nabble.com.

RE: Resizing an existing repository while keeping the revision numbering

Author Oleg X Rasskazov <oleg dot x dot rasskazov at jpmorgan dot com>
Full name Oleg X Rasskazov <oleg dot x dot rasskazov at jpmorgan dot com>
Date 2009-07-22 09:37:38 PDT
Message As it happens, subversion is really efficient with storing binary deltas, especially if you are talking
about builds of two nearby revisions for a library. It is very useful for regression testing, especially if you can not run all of the tests for each committed revision due to compute constraints.

Question though remains. Is it possible to add a flag to the svn load saying "start loading dump from revision nnnn?"
If that does not fit the design of subversion, what about a flag to svnadmin "put n empty(trivial change) revisions on top of the current repo?"

Doing svn ci of a dummy file via Perl script takes too long (about 2-3hours for 20k dummy revisions on my box).

A usage scenario is when you would like to have a mirror for all the revisions from now on, and do not bother with doing a 2-3 day sync over a slow connection for the whole repo.

best regards,
Oleg

-----Original Message-----
From: Andy Levy [mailto:andy dot levy at gmail dot com]
Sent: 22 July 2009 14:03
To: Andrey Repin
Cc: Oleg X Rasskazov
Subject: Re: Resizing an existing repository while keeping the revision numbering

On Wed, Jul 22, 2009 at 08:55, Andrey Repin<anrdaemon@f​reemail.ru> wrote:
> Greetings, Oleg X Rasskazov!
>
>> One of the ways we use subversion is to store compiled binaries of all the
>> revisions of a large library we are working on. Even with efficient
>> subversion storage algorithms (deltifying changes) and cheap hdds we are
>> running out of space.
>
> As far as I know, SVN deltify only text/* files.

Subversion performs a binary diff algorithm on all files for storage.
If the files/diffs are sufficiently large, then a completely new copy
will be stored.
This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.​com/pages/disclosure​s/email.

Re: Resizing an existing repository while keeping the revision numbering

Author levyam
Full name Andy Levy
Date 2009-07-22 06:03:00 PDT
Message On Wed, Jul 22, 2009 at 08:55, Andrey Repin<anrdaemon@f​reemail.ru> wrote:
> Greetings, Oleg X Rasskazov!
>
>> One of the ways we use subversion is to store compiled binaries of all the
>> revisions of a large library we are working on. Even with efficient
>> subversion storage algorithms (deltifying changes) and cheap hdds we are
>> running out of space.
>
> As far as I know, SVN deltify only text/* files.

Subversion performs a binary diff algorithm on all files for storage.
If the files/diffs are sufficiently large, then a completely new copy
will be stored.

Re: Resizing an existing repository while keeping the revision numbering

Author Andrey Repin <anrdaemon at freemail dot ru>
Full name Andrey Repin <anrdaemon at freemail dot ru>
Date 2009-07-22 06:00:08 PDT
Message Greetings, Oleg X Rasskazov!

> One of the ways we use subversion is to store compiled binaries of all the
> revisions of a large library we are working on. Even with efficient
> subversion storage algorithms (deltifying changes) and cheap hdds we are
> running out of space.

As far as I know, SVN deltify only text/* files.


--
WBR,
 Andrey Repin (anrdaemon at freemail dot ru) 22.07.2009, <16:41>

Sorry for my terrible english...

Resizing an existing repository while keeping the revision numbering

Author Oleg X Rasskazov <oleg dot x dot rasskazov at jpmorgan dot com>
Full name Oleg X Rasskazov <oleg dot x dot rasskazov at jpmorgan dot com>
Date 2009-07-22 02:33:57 PDT
Message Hi All,

One of the ways we use subversion is to store compiled binaries of all the revisions of a large library we are working on. Even with efficient subversion storage algorithms (deltifying changes) and cheap hdds we are running out of space.

Since earlier builds are now irrelevant to us I would like to purge first half of the repository, and this is easily done with

                svnadmin dump -rN:HEAD ... | svnadmin load ...

Problem is, when we do svn load, the revisions are renumbered from 1. This is undesired behaviour, as we have mirrors of the master repository, some of which we don't want to purge or want to purge independently. Another reason is that we have a mapping between binary svn revisions and source revisions stored elsewhere and do not want to remap it.

Is there a way of telling svn load to skip let say first N revisions? The only thing I can think of is making N temp file commits and trying to do svnadmin load next.

best regards,
Oleg



This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.​com/pages/disclosure​s/email.
Attachments
Messages per page: