>> $ svn up -r 5 --depth=empty branch/subdir
>> At revision 5. <== doesn't change anything
>
> Yes it does. It changes the working revision of branch/subdir from 3
> to 5. Since this update didn't bring in new explicit mergeinfo on
> branch/subdir, svn can now safely assume that the merge
On Thu, Nov 4, 2010 at 2:00 PM, Pieter-Jan Busschaert
wrote:
> Hello,
>
>>> There are a few things still not clear to me:
>>> 1) Before this svn update, svn stat -u shows nothing out-of-date, so
>>> it's strange that an update makes any difference.
>>
>> Try "svn stat -v", and you'll see the diffe
Hello,
>> There are a few things still not clear to me:
>> 1) Before this svn update, svn stat -u shows nothing out-of-date, so
>> it's strange that an update makes any difference.
>
> Try "svn stat -v", and you'll see the different working revisions of
> the files and dirs in the working copy. It
On Thu, Nov 4, 2010 at 12:30 PM, Mark Phippard wrote:
> On Thu, Nov 4, 2010 at 4:54 AM, Johan Corveleyn wrote:
>> I think this is known "as-designed" behavior, because of the
>> mixed-revision working copy system. Some nodes in your working copy
>> may be at different revisions than others (if yo
On Thu, Nov 4, 2010 at 4:54 AM, Johan Corveleyn wrote:
> I think this is known "as-designed" behavior, because of the
> mixed-revision working copy system. Some nodes in your working copy
> may be at different revisions than others (if you commit a change to
> ^/parent/child, child will be at a ne
[small nit: please don't top-post on this list (i.e. put your reply at
the bottom or inline, not above the text you're replying to).]
On Wed, Nov 3, 2010 at 3:20 PM, Pieter-Jan Busschaert
wrote:
> On 3 November 2010 10:17, Johan Corveleyn wrote:
>> On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Bus
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 17:18:54 +0100:
> On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
> >> (the upcoming 1.7 release will improve the situation a bit, IIUC: the
> >> not-affected-subtrees will no longe
On Wed, Nov 3, 2010 at 3:45 PM, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
>> (the upcoming 1.7 release will improve the situation a bit, IIUC: the
>> not-affected-subtrees will no longer have their mergeinfo updated all
>> the time, only if they are affec
Johan Corveleyn wrote on Wed, Nov 03, 2010 at 10:17:34 +0100:
> (the upcoming 1.7 release will improve the situation a bit, IIUC: the
> not-affected-subtrees will no longer have their mergeinfo updated all
> the time, only if they are affected by the merge).
That surprised me a little, but a quick
Hi,
I tested with a reproduction scenario and found this:
A) If I do an svn update on the top-level WC before the merge command,
the merge goes through OK and I can checkin.
B) If I don't do an svn update on the top-level WC before the merge
command, the merge goes wrong and svn complains about o
On Tue, Nov 2, 2010 at 11:29 AM, Pieter-Jan Busschaert
wrote:
> Hello,
>
> Here is some more information:
>
>>> Inside branch1/subfolder, we do a merge from trunk/subfolder.
>>
>> Do you mean trunk/project/subfolder here?
>
> yes
>
>> Anyway, branch1/subfolder does not have any mergeinfo,
>> since
Hello,
Here is some more information:
>> Inside branch1/subfolder, we do a merge from trunk/subfolder.
>
> Do you mean trunk/project/subfolder here?
yes
> Anyway, branch1/subfolder does not have any mergeinfo,
> since the previous merge was done on branch1. So Subversion
> does not know that yo
> In a quick test, we have a project which has the following
> structure:
>
> /trunk/project/subfolder/file
>
> Next, we create a branch from /trunk/project to
>
> /branches/project/branch1/
>
> We edit file on trunk a first time, changing line1 and commit
>
> Inside branch1, we do a merge fro
>
> Hello,
>
> In a quick test, we have a project which has the following structure:
>
> /trunk/project/subfolder/file
>
> Next, we create a branch from /trunk/project to
>
> /branches/project/branch1/
>
> We edit file on trunk a first time, changing line1 and commit
>
> Inside branch1, we do a mer
14 matches
Mail list logo
