[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: weird merge

From: Ryan Schmidt <subversion-2010a_at_ryandesign.com>
Date: Wed, 31 Mar 2010 03:42:03 -0500

On Mar 31, 2010, at 03:31, Cooke, Mark wrote:

>> On Mar 30, 2010, at 18:55, Xavier Noria wrote:
>>
>>> Can I tell to svn that it totally forget revisions < 3000 ?
>>
>> Doing so is a very invasive procedure. I don't recommend it.
>> It's likely to cause more problems than it solves.
>>
>>> Those are very old and we could just get rid of them it
>>> there was a chance that it solved the issue, it is a pity
>>> we need to deal with explicit revisions all the time,
>>> reflective merges...
>>>
>>> I don't know, perhaps around r2909 people did something
>>> with the repo, upgrading, ... no idea.
>>
> What about doing an "svnadmin dump -r 3000:head" of the repository
> starting at r3000, then load that in to a new repo and use that? I
> believe it should dump enough info to build 3000 then increment from
> there. However, I've never tried it.
>
> http://svnbook.red-bean.com/nightly/en/svn.reposadmin.maint.html#svn.rep
> osadmin.maint.filtering

Yes, that is the procedure I am talking about. It is very invasive, because it necessitates all users throwing away all working copies and checking them out again, means all old revision numbers (e.g. that have been recorded in issue tracker ticket notes, documentation, etc.) are no longer accurate, and does not necessarily result in space savings in the repository, which is what many people are looking for when they consider this procedure. (It may even increase the repository's size.)

Remember to keep the discussion on the list by using Reply All.
Received on 2010-03-31 10:42:40 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.