You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Neels Janosch Hofmeyr <ne...@elego.de> on 2009/08/13 02:30:09 UTC
tree conflict info
Hi again Tree-conflicts folks,
how about shortening the URLs in the "Tree-conflict" section of `svn info';
patch attached. This is what it does:
`svn info' on a tree-conflicted node with this patch looks like this, less
the comments:
[[[
[...]
URL: http://full.url/to/trunk/alpha [ <-- as usual... ]
[...]
Tree conflict: local edit, incoming delete upon update
Source left: (file) ^/trunk/alpha@1 [ <-- these URLs ]
Source right: (file) ^/trunk/alpha@2 [ <-- were shortened ]
]]]
Currently, this section often looks overcrowded like this:
[[[
[...]
URL: file:///home/neels/svn/tests/tc_replace_update/m201b7297/repos/trunk/alpha
[...]
Tree conflict: local delete, incoming delete upon update
Source left: (file)
file:///home/neels/svn/tests/tc_replace_update/m201b7297/repos/trunk/alpha@1
Source right: (none)
file:///home/neels/svn/tests/tc_replace_update/m201b7297/repos/trunk/alpha@2
]]]
In many cases, the repos URL is printed in full further above, and repeating
the full URLs is redundant. However, when the current node kind is absent,
`svn info' is pretty quiet; this would be a whole info:
[[[
$ svn info m201b7297/trunk2/alpha
Path: m201b7297/trunk2/alpha
Name: alpha
Node Kind: none
Tree conflict: local delete, incoming delete upon update
Source left: (file) ^/trunk/alpha@1
Source right: (none) ^/trunk/alpha@2
]]]
I'd say it is still okay to use the caret notation. The parent dir's URL is
available from the working copy. The benefit of readability outweighs the
lack of full info.
There won't ever be a different repository's URL in there, will there.
Agreed?
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383099
Re: tree conflict info
Posted by Neels Janosch Hofmeyr <ne...@elego.de>.
Stefan Sperling wrote:
> On Thu, Aug 13, 2009 at 10:21:31AM -0400, Mark Phippard wrote:
>> On Thu, Aug 13, 2009 at 10:18 AM, Stefan Sperling<st...@elego.de> wrote:
>>> On Thu, Aug 13, 2009 at 01:49:09PM +0100, Julian Foad wrote:
>>>> Neels Janosch Hofmeyr wrote:
>>>>> There won't ever be a different repository's URL in there, will there.
>>>> In a cross-repository merge? But I don't think we need to handle that at
>>>> the moment, do we?
>>> Didn't CMike do extra work to make merges from arbitrary URLs work?
>> Yes, but I do not think these can produce tree conflicts. They are
>> equivalent to --ignore-ancestry merges.
>
> A merge can cause tree conflicts no matter whether ancestry is ignored
> or not. Mikes log message talks about adding files. So just having a
> file added at the same place or a missing parent directory should
> be enough to trigger a tree conflict.
So true.
Implemented more intelligent caret notation URLling in r38758.
That made it become quite a complex tweak...
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383739
Re: tree conflict info
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 13, 2009 at 10:21:31AM -0400, Mark Phippard wrote:
> On Thu, Aug 13, 2009 at 10:18 AM, Stefan Sperling<st...@elego.de> wrote:
> > On Thu, Aug 13, 2009 at 01:49:09PM +0100, Julian Foad wrote:
> >> Neels Janosch Hofmeyr wrote:
> >> > There won't ever be a different repository's URL in there, will there.
> >>
> >> In a cross-repository merge? But I don't think we need to handle that at
> >> the moment, do we?
> >
> > Didn't CMike do extra work to make merges from arbitrary URLs work?
>
> Yes, but I do not think these can produce tree conflicts. They are
> equivalent to --ignore-ancestry merges.
A merge can cause tree conflicts no matter whether ancestry is ignored
or not. Mikes log message talks about adding files. So just having a
file added at the same place or a missing parent directory should
be enough to trigger a tree conflict.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383327
Re: tree conflict info
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Thu, Aug 13, 2009 at 10:18 AM, Stefan Sperling<st...@elego.de> wrote:
>> On Thu, Aug 13, 2009 at 01:49:09PM +0100, Julian Foad wrote:
>>> Neels Janosch Hofmeyr wrote:
>>>> There won't ever be a different repository's URL in there, will there.
>>> In a cross-repository merge? But I don't think we need to handle that at
>>> the moment, do we?
>> Didn't CMike do extra work to make merges from arbitrary URLs work?
>
> Yes, but I do not think these can produce tree conflicts. They are
> equivalent to --ignore-ancestry merges.
That's correct.
(And by golly I *love* the foreign repository merge feature!! I've
completely reworked my approach to vendor branch management around that stuff.)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383312
Re: tree conflict info
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Aug 13, 2009 at 10:18 AM, Stefan Sperling<st...@elego.de> wrote:
> On Thu, Aug 13, 2009 at 01:49:09PM +0100, Julian Foad wrote:
>> Neels Janosch Hofmeyr wrote:
>> > There won't ever be a different repository's URL in there, will there.
>>
>> In a cross-repository merge? But I don't think we need to handle that at
>> the moment, do we?
>
> Didn't CMike do extra work to make merges from arbitrary URLs work?
Yes, but I do not think these can produce tree conflicts. They are
equivalent to --ignore-ancestry merges.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383302
Re: tree conflict info
Posted by Stefan Sperling <st...@elego.de>.
On Thu, Aug 13, 2009 at 01:49:09PM +0100, Julian Foad wrote:
> Neels Janosch Hofmeyr wrote:
> > There won't ever be a different repository's URL in there, will there.
>
> In a cross-repository merge? But I don't think we need to handle that at
> the moment, do we?
Didn't CMike do extra work to make merges from arbitrary URLs work?
------------------------------------------------------------------------
r29742 | cmpilato | 2008-03-06 14:58:07 +0000 (Thu, 06 Mar 2008) | 17 lines
Enhance (complete?) our existing support for merges from foreign
repositories by treating merged adds of files and directories as
regular adds (instead of adds with history).
* subversion/libsvn_client/merge.c
(merge_file_added, merge_dir_added): Don't calculate copyfrom
information for merged adds when the merge source repository is
not the same repository as the one from which the merge target
working copy was checked out.
ALSO (accidentally committed):
* contrib/client-side/svnmerge/svnmerge-migrate-history.py
Begin trying to deal with the differences between svnmerge's
property syntax and Subversion's svn:mergeinfo syntax.
(### This bit reverted in r29743. ###)
------------------------------------------------------------------------
I'd say we should only shorten URLs in svn info output to ^ if the URL
matches the repository root recorded for the item.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383301
Re: tree conflict info
Posted by Julian Foad <ju...@btopenworld.com>.
Neels Janosch Hofmeyr wrote:
> Hi again Tree-conflicts folks,
>
> how about shortening the URLs in the "Tree-conflict" section of `svn info';
> patch attached. This is what it does:
>
> `svn info' on a tree-conflicted node with this patch looks like this, less
> the comments:
> [[[
> [...]
> URL: http://full.url/to/trunk/alpha [ <-- as usual... ]
> [...]
> Tree conflict: local edit, incoming delete upon update
> Source left: (file) ^/trunk/alpha@1 [ <-- these URLs ]
> Source right: (file) ^/trunk/alpha@2 [ <-- were shortened ]
> ]]]
Nice.
> [...], when the current node kind is absent,
> `svn info' is pretty quiet; this would be a whole info:
>
> [[[
> $ svn info m201b7297/trunk2/alpha
> Path: m201b7297/trunk2/alpha
> Name: alpha
> Node Kind: none
> Tree conflict: local delete, incoming delete upon update
> Source left: (file) ^/trunk/alpha@1
> Source right: (none) ^/trunk/alpha@2
> ]]]
>
> I'd say it is still okay to use the caret notation. The parent dir's URL is
> available from the working copy. The benefit of readability outweighs the
> lack of full info.
I agree.
> There won't ever be a different repository's URL in there, will there.
In a cross-repository merge? But I don't think we need to handle that at
the moment, do we?
Patch looks good. +1.
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2383271