Re: Adjust revision in new repository

On Mon, Sep 4, 2023 at 8:36 AM Magnus Lyrberg
<[email protected]> wrote:
>
> On Fri, Sep 1, 2023 at 3:15 PM Johan Corveleyn <[email protected]> wrote:
>>
>> On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg
>> <[email protected]> wrote:
>> > Thank you. This is very similar to our current solution. It would
>> > however be nice to avoid a lot of empty commits, hence my
>> > engagement in this list asking for alternative solutions.
>> >
>> > But perhaps there are none.
>>
>> I'm not sure, but it sounds like that would be quite a hack, and I
>> don't think it will be possible.
>>
>> The repository still has to give a sane reply if a user asks for "svn
>> update -r 2" or "svn ls https://server/svn@1". If those revisions
>> really don't exist, what should the server answer? So I don't think
>> you can avoid creating those revisions, but you can leave them empty,
>> as suggested.
>>
>> What is the problem in having those empty revisions anyway? I assume
>> they hardly take up any diskspace. If that's the only price you have
>> to pay for having this "old cruft removed but still original
>> rev-numbers repository", it sounds like a good deal to me (and it's
>> still a correctly working repository that behaves as designed).
>
>
> Theoretically you could get the same answer from the server as when you
> ask for a revision that does not yet exist. I see your point though.
>
> There is some concern that having 180000 empty commits might impact
> the performance of the repository. I assume each commit still has an entry
> in the database etc, even if it does not use a lot of disk.

Then it's time to revisit your basic architecture to point to a new
repo with a wildly reduced history, and *use tags*. Subversion was
written to preserve history and treat it as immutable. Replacing
10,000 commits with empty commits just to preserve the numbering for a
later commit is..... very much against its design goals, and likely to
be much more expensive than switching to tag bsed references ASAP. I
sympathize with the desire to take what seems like a simple path, but
it sounds like you have to switch to a new repo *anyway* Take
advantage of the  opportunity to strip it for performance.

And oh, the fastest way to strip is probably to pull the repo into a
git clone, discard unwelcome branches, run "git gc ---aggressive" and
push it back to a new repo.. Subversion was not written to discard
unused history easily, git does a fair job and does pretty well
publishing back to another subversion repo.