[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Tree conflicts raised by third-party software

From: David Glasser <glasser_at_davidglasser.net>
Date: Wed, 7 Jan 2009 17:37:57 -0800

Wait, we're documenting svn_wc__something as something third-party
developers should use and rely on???

--dave

On Wed, Jan 7, 2009 at 2:44 PM, Mark Phippard <mphippard_at_collab.net> wrote:
> Is there any reason this cannot just be in trunk? Maybe just put it
> in contrib if there is concern about making it an "official" command
> line tool?
>
> Mark
>
>
> On Tue, Dec 9, 2008 at 11:13 PM, Neels Janosch Hofmeyr <neels_at_elego.de> wrote:
>> Hi Tree-conflicts and TruMerge folks,
>>
>> we've got a commandline tool ready that allows third-party software to raise
>> tree-conflicts in a working copy. I've reviewed Julian Foad's approach and
>> all I could add was minor output polishing. I can successfully build and use
>> the tool to raise a tree-conflict externally, upon which the working copy is
>> blocked as expected, and the conflict can be resolved as expected.
>>
>> For convenience, find attached the current online-help output of the tool
>> and the current patch you would apply to any given (tree-conflict aware)
>> version of the Subversion source code.
>>
>> I've also checked in Julians first version and my review changes into branch
>> svnraisetc on The Subversion Repository.
>>
>> To give it a first try, the simplest way is to checkout the branched
>> Subversion source tree like:
>>
>> svn co https://svn.collab.net/repos/svn/branches/svnraisetc
>>
>> and build that like any usual Subversion source tree. That will, in addition
>> to building the complete Subversion, build (and install, if asked to) the
>> executable file
>> subversion/svnraisetreeconflict/svnraisetreeconflict
>> Note that you get a svnraisetreeconflict tool version that is compatible
>> with your current compile, and thus you want to run your sandbox trials
>> using also svn, svnserve and svnadmin from that same compile.
>>
>> This program can be run on a working copy path to raise a tree conflict on
>> that path. Running `svnraisetreeconflict --help' prints out the list of
>> arguments needed to do so.
>>
>> A difficulty is to provide sensible information for raising the conflict.
>> However, this information is mostly used for printing it upon "svn info", so
>> it is not *really* necessary to be exact there. We're happy to assist.
>>
>> To get the most recent version in future, one would have to get a Subversion
>> source tree and apply the (simple) changes that the branch has in respect to
>> its most recently synced trunk equivalent... We'd again be happy to assist.
>>
>> Also note this, quoting Julian Foad:
>>> (This little program has rough edges, of course. The UI is pretty
>>> primitive. I also noticed if you try to raise another tree conflict on a
>>> victim that already has one, it gives a sensible error message but the
>>> WC becomes locked and cleanup doesn't work.)
>>
>> Feedback is most welcome, especially from the TruMerge side.
>> Thanks Julian!
>> ~Neels
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981990
>> Hi Tree-conflicts and TruMerge folks,
>>
>> we've got a commandline tool ready that allows third-party software to raise
>> tree-conflicts in a working copy. I've reviewed Julian Foad's approach and
>> all I could add was minor output polishing. I can successfully build and use
>> the tool to raise a tree-conflict externally, upon which the working copy is
>> blocked as expected, and the conflict can be resolved as expected.
>>
>> For convenience, find attached the current online-help output of the tool
>> and the current patch you would apply to any given (tree-conflict aware)
>> version of the Subversion source code.
>>
>> I've also checked in Julians first version and my review changes into branch
>> svnraisetc on The Subversion Repository.
>>
>> To give it a first try, the simplest way is to checkout the branched
>> Subversion source tree like:
>>
>> svn co https://svn.collab.net/repos/svn/branches/svnraisetc
>>
>> and build that like any usual Subversion source tree. That will, in addition
>> to building the complete Subversion, build (and install, if asked to) the
>> executable file
>> subversion/svnraisetreeconflict/svnraisetreeconflict
>> Note that you get a svnraisetreeconflict tool version that is compatible
>> with your current compile, and thus you want to run your sandbox trials
>> using also svn, svnserve and svnadmin from that same compile.
>>
>> This program can be run on a working copy path to raise a tree conflict on
>> that path. Running `svnraisetreeconflict --help' prints out the list of
>> arguments needed to do so.
>>
>> A difficulty is to provide sensible information for raising the conflict.
>> However, this information is mostly used for printing it upon "svn info", so
>> it is not *really* necessary to be exact there. We're happy to assist.
>>
>> To get the most recent version in future, one would have to get a Subversion
>> source tree and apply the (simple) changes that the branch has in respect to
>> its most recently synced trunk equivalent... We'd again be happy to assist.
>>
>> Also note this, quoting Julian Foad:
>>> (This little program has rough edges, of course. The UI is pretty
>>> primitive. I also noticed if you try to raise another tree conflict on a
>>> victim that already has one, it gives a sensible error message but the
>>> WC becomes locked and cleanup doesn't work.)
>>
>> Feedback is most welcome, especially from the TruMerge side.
>> Thanks Julian!
>> ~Neels
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=981990
>>
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
>

-- 
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
Received on 2009-01-08 09:37:39 CET

This is an archived mail posted to the Subversion Dev mailing list.