Re: Adjust revision in new repository
On Mon, Sep 4, 2023 at 8:36 AM Magnus Lyrberg wrote: > > On Fri, Sep 1, 2023 at 3:15 PM Johan Corveleyn wrote: >> >> On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg >> 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 18 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.
Re: Adjust revision in new repository
On Thu, Aug 31, 2023 at 8:21 AM Magnus Lyrberg wrote: > > Hello. > > I'm not subscribed so please CC me in any response. > > We have, most unfortunately and for historical reasons, > a very hard dependency on the revision number in subversion. > > Our current repository has become large and unwieldy, and we > want to move to a fresh repository. The history is not very important, > we are ok to start from scratch, but loosing the revision number > would be incredibly costly. Stop. Do not pass go, do not collect $200. "Incredibly costly" is unlikely to be as expensive as supporting a jury-rig like this. Go back and rewrite your base software to use tags If you can't rewrite it, make a copy of the repo somewhere else to play with it,. And slap the wrist of the silly person who originally decided to use revision numbers. And that said, you may actually be able to strip down the repo by a large factor and set a tag to match that old revision number, skipping right past the size issue.
Re: Adjust revision in new repository
On Mon, Sep 4, 2023 at 8:36 AM Magnus Lyrberg wrote: > There is some concern that having 18 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. Are you doing this for performance? I doubt you will see any improvements even if you did not care about the revision numbers and just created a new repo with a handful of revisions. SVN performance is not impacted by the number of revisions with the only exception being the tools you use to backup and restore the repository. If anything, having a single revision with a lot of changes in it hurts performance of some commands. For example svn log -v is really harmed by having a single revision with a lot of changed paths. Mark
Re: Adjust revision in new repository
On Fri, Sep 1, 2023 at 3:15 PM Johan Corveleyn wrote: > On Fri, Sep 1, 2023 at 2:47 PM Magnus Lyrberg > 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 18 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. Best regards Magnus Lyrberg
