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
10 matches
Mail list logo
