bad idea, and should be discouraged. A revision that contains
svn:mergeinfo changes should only contain the file and structure
> changes logically equivalent to the revisions that have been merged.
Sure, but back to Joël's question: that still does not mean SVN can
assume this "merge changset"
Daniel Becroft writes:
> We've only just started using feature branches, and most of the time, our
> merges are one way (trunk -> branch), until, eventually, we need to
> reintegrate (or just dump the branch). One the few occasions that a branch
> -> trunk is required, we just do it manually. Le
On Fri, Apr 30, 2010 at 10:52 PM, Greg Troxel wrote:
>
> Daniel Becroft writes:
>
> > On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud
> wrote:
> >
> >> Like yourself, I initially though that it would be able to deal with
> this,
> >>> but it doesn't seem to (and there is probably a very good rea
Daniel Becroft writes:
> On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud wrote:
>
>> Like yourself, I initially though that it would be able to deal with this,
>>> but it doesn't seem to (and there is probably a very good reason why it
>>> can't).
>>>
>>
>> I would be interested in knowing this
On Thu, Apr 29, 2010 at 6:45 PM, Joël Conraud wrote:
> Like yourself, I initially though that it would be able to deal with this,
>> but it doesn't seem to (and there is probably a very good reason why it
>> can't).
>>
>
> I would be interested in knowing this "very good reason why it can't". I'
On Thu, Apr 29, 2010 at 9:17 PM, Vadym Chepkov wrote:
>
> On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote:
>
>
>
> [b2]$ svn merge --dry-run ^/branches/b1
>> --- Merging r2 through r4 into '.':
>>C README
>> Summary of conflicts:
>> Tree conflicts: 1
>>
>
>
> After r3, you'll need to do a
> [b2]$ svn merge --dry-run ^/branches/b1
> --- Merging r2 through r4 into '.':
>C README
> Summary of conflicts:
> Tree conflicts: 1
and yet another strange thing about it.
There is no way to automatically resolve a conflict like this.
no matter what flag I use --accept mine-conflict, mine
On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote:
>
> [b2]$ svn merge --dry-run ^/branches/b1
> --- Merging r2 through r4 into '.':
>C README
> Summary of conflicts:
> Tree conflicts: 1
>
>
> After r3, you'll need to do a '--record-only' merge of r4 into the second
> branch:
>
> (unte
>
> Like yourself, I initially though that it would be able to deal with this,
> but it doesn't seem to (and there is probably a very good reason why it
> can't).
>
I would be interested in knowing this "very good reason why it can't". I'm
not questioning its validity, I'm confident this good reas
On Thu, Apr 29, 2010 at 10:08 AM, Vadym Chepkov wrote:
> Hi,
>
> I know, this is maybe not the best practice, but, unfortunately, our
> subversion users do this all the time: they merge form one branch to another
> back and forward.
> The question is, how to properly do it without introducing co
Hi,
I know, this is maybe not the best practice, but, unfortunately, our
subversion users do this all the time: they merge form one branch to another
back and forward.
The question is, how to properly do it without introducing conflicts.
Here is the test case, which one would think should be handl
11 matches
Mail list logo
