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

Re: Issue 2836

From: Neels J. Hofmeyr <neels_at_elego.de>
Date: Wed, 29 Oct 2008 07:11:54 +0100

Just some unqualified advice: Best simply start writing a patch, you'll run
into problems soon enough if there are any. Implementation discussions are
much easier when an example approach is at hand. And it's fun, too. ;)

~Neels

Troy Curtis Jr wrote:
> I've been keeping half an eye on the list and noticed that the 1.6 branch
> was fast approaching, so I wanted to know if the 'block' feature of
> merge-tracking had been addressed yet. Apparently not (
> http://subversion.tigris.org/issues/show_bug.cgi?id=2836). This is
> definitely something I would have to have before upgrading and migrating all
> of my merge info from svnmerge.py to the built-in merge. The "work around"
> isn't, as in my case is does not remove the need for the svnmerge script,
> therefore the main reason to migrate is gone!
>
> The last message I saw was from Blair saying this was a pretty basic feature
> that shouldn't have to wait until 1.6 (
> http://svn.haxx.se/dev/archive-2007-07/0391.shtml)...well it's here! :)
>
> Has anyone else thought any on this? If so perhaps we could pull together
> some ideas. I realize it might be a little late for 1.6 at this point, but
> I would really like to see the feature make it into Subversion. I might
> even be willing/able to make the patch myself depending on the size of it
> after implementation discussions.
>
> It seems pretty straight-foward, but then again I haven't taken the time to
> really look at the merge-tracking implementation and just how well it could
> drop in place. What concerns do people see?
>
> Just wanted to raise awareness of this to anyone that was interested.
>
> Troy

Received on 2008-10-29 07:12:20 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.