On Mon, Sep 4, 2023 at 8:36 AM Magnus Lyrberg <magnus.lyrb...@elk-studios.com> wrote: > > On Fri, Sep 1, 2023 at 3:15 PM Johan Corveleyn <jcor...@gmail.com> wrote: >> >> On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg >> <magnus.lyrb...@elk-studios.com> 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.