You are viewing a plain text version of this content. The canonical link for it is here.

Posted to users@subversion.apache.org by Xavier Noria <fx...@hashref.com> on 2010/03/25 10:09:49 UTC

weird merge

I am using 1.6 and was told that nowadays explicit revision numbers
are not needed for branching merging in the most common use case at
least.

That is, after you create branch b from trunk, you work on b,
occasionally you sync with trunk this way:

    cd b
    svn merge ^/trunk .

and when you are done in b finally

    cd trunk
    svn merge --reintegrate ^/branches/b .

First, that is correct right?

Alright, assuming it is, I've tried this in the project I am working on, and

    svn merge ^/trunk .

instead of being silent says

    --- Merging r2 through r2909 into '.'

and then a ton of tree conflicts appear. But that is kind of weird
because this project is at revision ~28000, why a range from 2 to
2909?

I am not into svn and do not know what to do. Can anyone guess what
could be happening?

Re: weird merge

Posted by Ryan Schmidt <su...@ryandesign.com>.

On Mar 31, 2010, at 04:07, Cooke, Mark wrote:

> I thought there was a way to persuade "svnadmin load" to keep the
> revision numbers but on looking I cannot find anything.  It seems to
> renumber revs by default.  However, I have a repository that I created
> from a VSS conversion and used dumpfilter on and the revisions start at
> 282, so it must be possible somehow...

Agreed, it should be possible to do.

> Working copies can be relocated (if you keep the same repo UUID)

But you must not keep the same UUID, because, now that you've removed historical revisions, your repository has different contents than it used to, hence it is a different repository and must now have a new UUID.

RE: weird merge

Posted by "Cooke, Mark" <ma...@siemens.com>.

> 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.)
> 
I thought there was a way to persuade "svnadmin load" to keep the
revision numbers but on looking I cannot find anything.  It seems to
renumber revs by default.  However, I have a repository that I created
from a VSS conversion and used dumpfilter on and the revisions start at
282, so it must be possible somehow...

Working copies can be relocated (if you keep the same repo UUID) but I
believe that the renumbered revisions would still be a show stopper.
I'm confused now!

> Remember to keep the discussion on the list by using Reply All.
> 
Dang, thanks for the reminder.

~ Mark C

Re: weird merge

Posted by Ryan Schmidt <su...@ryandesign.com>.

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.