[Numpy-discussion] Using svnmerge on numpy: am I missing something ?

David Cournapeau david@ar.media.kyoto-u.ac...
Tue Jan 8 20:56:34 CST 2008

Robert Kern wrote:
> David Cournapeau wrote:
>> Matthieu Brucher wrote:
>>>     > Oups, safe for the "/trunk:1-2871" part. This should be deleted
>>>     before
>>>     > a commit to the trunk, I think.
>>>     Yes, that's what I (quite unclearly) meant: since revision numbers are
>>>     per- repository in svn, I don't understand the point of tracking trunk
>>>     revisions: I would think that tracking the last merged version for
>>>     each
>>>     branch to be enough (for the kind of merge svn does, at least). If
>>>     trunk
>>>     version are tracked, then I would expect two branches using
>>>     svnmerge to
>>>     clash each other,
>>> In fact, the trunk should be tracked from all the branches, although 
>>> there will be the problem with merging the different branches (I did 
>>> not have many troubles with that, but I only tried with a few 
>>> differences) into the trunk. I don't think only one branch wants to be 
>>> up to date with the trunk ;).
>> Sure, that's what I was trying to do (tracking the trunk). But if 
>> svnmerge needs the information from the trunk, this means each branch 
>> will need a different value, whereas only one value is possible...
> IIRC, its presence in the trunk/'s svnmerge-integrated property is a mistake. It 
> belongs in each of the branches independently. For some reason, it got merged 
> into the trunk from one of the branches by mistake, possibly because someone 
> started merge tracking with svnmerge then another used "svn merge". It should be 
> removed.
I have to confess I may be the one who screwed up when creating one of 
the sconc branch (I normally take care to never commit to the numpy 
trunk, but I may have missed it using svnmerge).



More information about the Numpy-discussion mailing list