[Fwd: svn 1.5.1 merge clue required]

[Lawrence Stewart <ls...@room52.net>]

Hi all,

I haven't had any nibbles from the users@ mailing list so I'm hoping 
someone here might have some thoughts...

Cheers,
Lawrence

Re: [Fwd: svn 1.5.1 merge clue required]

[Karl Fogel <kf...@red-bean.com>]

Lawrence Stewart <ls...@room52.net> writes:
> Karl Fogel wrote:
>> "C. Michael Pilato" <cm...@collab.net> writes:
>>>> I haven't had any nibbles from the users@ mailing list so I'm hoping
>>>> someone here might have some thoughts...
>>> Note for the future:  dev@ is *not* part of some grand escalation policy of
>>> users@.
>>
>> :-)  A more detailed explanation of that may be found here:
>>
>>    http://subversion.tigris.org/mailing-lists.html#where
>>
>> [deliberately not CC'ing dev@ on this, I've posted it there before]

Hey, Lawrence (and everybody),

It's my fault, not Lawrence's, that his reply here got posted to the
list.  My private mail to him still had a "Mail-followup-to:" header
pointing to the list (long story).

> Duly noted. I have followed both lists for some time and was aware of
> the separate list charters. In my (perhaps misguided) defence, I would
> not have forwarded my query on to dev@ unless I had strong reason to
> believe the behaviour I was observing was indicative of a bug in svn
> or the documentation. In retrospect, I can see that a direct forward
> of my email from users@ to dev@ was inappropriate, as the subject and
> phrasing of that email was targeted at the users@ audience.

Ah, okay.  Thanks for your understanding; rethreading in bug-report form
is welcome of course.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Fwd: svn 1.5.1 merge clue required]

[Lawrence Stewart <ls...@room52.net>]

Hello to you both,

Karl Fogel wrote:
> "C. Michael Pilato" <cm...@collab.net> writes:
>>> I haven't had any nibbles from the users@ mailing list so I'm hoping
>>> someone here might have some thoughts...
>> Note for the future:  dev@ is *not* part of some grand escalation policy of
>> users@.
> 
> :-)  A more detailed explanation of that may be found here:
> 
>    http://subversion.tigris.org/mailing-lists.html#where
> 
> [deliberately not CC'ing dev@ on this, I've posted it there before]

Duly noted. I have followed both lists for some time and was aware of 
the separate list charters. In my (perhaps misguided) defence, I would 
not have forwarded my query on to dev@ unless I had strong reason to 
believe the behaviour I was observing was indicative of a bug in svn or 
the documentation. In retrospect, I can see that a direct forward of my 
email from users@ to dev@ was inappropriate, as the subject and phrasing 
of that email was targeted at the users@ audience.

C. Michael, I'll respond to your suggestion via a reply to my original 
post to users@.

All, please accept my apologies, as it was not my intention to come 
across as a petulant user demanding an answer to a general question.

Cheers,
Lawrence

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: [Fwd: svn 1.5.1 merge clue required]

["C. Michael Pilato" <cm...@collab.net>]

Lawrence Stewart wrote:
> Hi all,
> 
> I haven't had any nibbles from the users@ mailing list so I'm hoping
> someone here might have some thoughts...

Note for the future:  dev@ is *not* part of some grand escalation policy of
users@.

> My understanding of the output of the above commands is that running
> "svn merge https://xxx/vendor/freebsd/8.x 8.x" should do nothing except
> update the mergeinfo entry on the 8.x directory to something like
> "/vendor/freebsd/8.x:95-474". However, I get the following:
> 
> root@lstewart3# svn merge https://xxx/vendor/freebsd/8.x 8.x
> Conflict discovered in '8.x/lib/libarchive/archive_entry_strmode.c'.
> Select: (p) postpone, (df) diff-full, (e) edit,
>         (h) help for more options:
> 
> etc. etc. for a whole heap of file changes being pulled in from the
> vendor branch. Props get changed, files added/deleted. etc.

If you do a --dry-run merge, does that help you determine what revisions are
incoming?

-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand