On Tue, Aug 24, 2010 at 08:59:32AM +0100, Julian Foad wrote:
> On Tue, 2010-08-24, Stefan Sperling wrote:
> > On Mon, Aug 23, 2010 at 06:40:39PM +0100, Julian Foad wrote:
> > > You seem to be talking only about the case where the (locally added)
> > > target is the root of the whole merge, and sayi
On Tue, 2010-08-24, Stefan Sperling wrote:
> On Mon, Aug 23, 2010 at 06:40:39PM +0100, Julian Foad wrote:
> > You seem to be talking only about the case where the (locally added)
> > target is the root of the whole merge, and saying that lack of ancestral
> > relationship between the source node an
On Mon, Aug 23, 2010 at 06:40:39PM +0100, Julian Foad wrote:
> You seem to be talking only about the case where the (locally added)
> target is the root of the whole merge, and saying that lack of ancestral
> relationship between the source node and this target node doesn't
> matter. Maybe the use
On Mon, 2010-08-23 at 18:40 +0100, Julian Foad wrote:
> On Mon, 2010-08-23 at 18:43 +0200, Stefan Sperling wrote:
> > On Wed, Aug 04, 2010 at 12:32:06PM -0400, Paul Burba wrote:
> > > On Wed, Aug 4, 2010 at 12:14 PM, Julian Foad
> > > wrote:
> > > > On Wed, 2010-08-04 at 11:23 -0400, Paul Burba w
On Mon, Aug 23, 2010 at 12:35 PM, Stefan Sperling wrote:
> One more question: In case a file/directory has been copied, does that
> affect its implicit mergeinfo in any way?
Definitely, a copy *has* implicit mergeinfo, whereas a local addition has none.
Think of it like this:
Do a URL-to-WC co
On Mon, 2010-08-23 at 18:43 +0200, Stefan Sperling wrote:
> On Wed, Aug 04, 2010 at 12:32:06PM -0400, Paul Burba wrote:
> > On Wed, Aug 4, 2010 at 12:14 PM, Julian Foad
> > wrote:
> > > On Wed, 2010-08-04 at 11:23 -0400, Paul Burba wrote:
> > >> On Wed, Aug 4, 2010 at 10:52 AM, Julian Foad
> >
On Wed, Aug 04, 2010 at 12:32:06PM -0400, Paul Burba wrote:
> On Wed, Aug 4, 2010 at 12:14 PM, Julian Foad wrote:
> > On Wed, 2010-08-04 at 11:23 -0400, Paul Burba wrote:
> >> On Wed, Aug 4, 2010 at 10:52 AM, Julian Foad
> >> wrote:
> >> > if the tree conflict detection policy is "relaxed", and
alm.
I've committed this change, and two regression tests, in r988188.
Stephen Butler help me figure out some related issues in our test suite,
which we fixed in r988144 and r988175.
Note that while my original post was only about merging into locally added
files, I discovered that merging in
On Wed, Aug 4, 2010 at 12:14 PM, Julian Foad wrote:
> On Wed, 2010-08-04 at 11:23 -0400, Paul Burba wrote:
>> On Wed, Aug 4, 2010 at 10:52 AM, Julian Foad
>> wrote:
>> > Stefan Sperling wrote:
>> >> It does not seem possible right now to merge into locally added
>> >> files, because the Subversi
On Wed, 2010-08-04 at 11:23 -0400, Paul Burba wrote:
> On Wed, Aug 4, 2010 at 10:52 AM, Julian Foad wrote:
> > Stefan Sperling wrote:
> >> It does not seem possible right now to merge into locally added
> >> files, because the Subversion assumes that the merge target will
> >> always have a corres
On Wed, Aug 4, 2010 at 10:29 AM, Stefan Sperling wrote:
> I haven't run make check yet either, in fear that lots of merge
> tests will just start to fail on me when I try.
I forget to mention in my earlier response, I ran [ra_serf] x
[merge_tests.py | merge_reintegrate_tests.py |
merge_tree_conf
On Wed, Aug 4, 2010 at 10:52 AM, Julian Foad wrote:
> Stefan Sperling wrote:
>> It does not seem possible right now to merge into locally added
>> files, because the Subversion assumes that the merge target will
>> always have a corresponding URL in the repository, and errors out.
>>
>> With a bit
Stefan Sperling wrote:
> It does not seem possible right now to merge into locally added
> files, because the Subversion assumes that the merge target will
> always have a corresponding URL in the repository, and errors out.
>
> With a bit of special-casing during error handling in a few places,
>
While trying to improve input validation in svn merge, I stumbled
across an apparently unsupported use case.
It does not seem possible right now to merge into locally added
files, because the Subversion assumes that the merge target will
always have a corresponding URL in the repository, and error
14 matches
Mail list logo