> On Sat, Mar 1, 2008 at 12:17 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> "Mark Phippard" <markphip_at_gmail.com> writes:
>> >> > He is making changes to properties as part of the merge process
>> >> > (changing history). We do not have a mechanism for conveying this to
>> >> > the working copy (one of the problems svn obliterate would also have
>> >> > to solve).
>> This isn't really related to this thread, and I don't expect (or need)
>> a reply, but please note that we've pretty much agreed to punt on
>> working-copy handling of obliterate. That is, it's okay to implement
>> just the repository-side part, and let people re-check-out working
>> copies or whatever.
>> The reason I say this is that there has been so much FUD and
>> misunderstanding about 'obliterate' on users@ and in the issue tracker
>> that I want to prevent any further perpetuation of the myth that
>> client-side issues are what's holding it up (for example, see
>> http://subversion.tigris.org/issues/show_bug.cgi?id=516#desc71 and the
>> comments preceding it).
> I'm interesting in what Gavin comes up with as long as it doesn't
> become another monster feature with big delays.
You and me both!
I would certainly like to see some path whereby development might occur
And I am currently going through some of the outstanding issues/ /bugs,
in the hope that I might be able to offer something along the lines of;
By completing work for issue #xxxx - we enable "this" which would be
useful / a requirement for obliterate.
It is some pretty "dry" reading - especially to someone with no SVN
development know-how or history, though I am progressing...
Gavin 'Beau 'Baumanis
The Spidernet Web Design
P: 03 9750-6313 (+61 39750 6313)
M: 0438 545 586 (+61 438 545 586)
Received on 2008-03-01 16:20:09 CET
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org