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

Re: reducing code bloat by removing svnpatch? (except unidiff)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 28 Aug 2009 15:37:06 -0400

Stefan Sperling wrote:
> On Fri, Aug 28, 2009 at 11:36:44AM -0400, C. Michael Pilato wrote:
>> Stefan Sperling wrote:
>>> On Fri, Aug 28, 2009 at 11:07:30AM -0400, C. Michael Pilato wrote:
>>>> Is the plan to remove the support, cut a new branch, and re-add the support
>>>> on that branch with a note about the need for refactoring?
>>> I guess we can just
>>> svn copy ^/trunk_at_rev-before-it-was-removed ^/branches/svnpatch
>>> as soon as someone wants to work on it again.
>>>
>>> Or they can just work on it on trunk.
>>>
>>> All the code of the old implementation would still be in the history,
>>> for reference.
>> I think I'd rather have the code more "visible" on a branch or something
>> than just "in the history for reference", just so there's that visual
>> reminder -- and the email one Hyrum will send us every six months when he
>> gets into a branch-purging mood :-). Branch before removing is fine, and +1
>> from me on removing the bloated code for now.
>
> I think that anyone working on this would want to start with a clean
> state anyway, rather than with what there is now. But I may be mistaken.
>
> So if you think a branch as a reminder is useful we can do that.
> But usually we use issues for this purpose. Would an issue also do,
> with milestone 1.7-consider?

There's a negligible chance that it'll be me working on re-adding this code,
so *shrug* whatever floats your boat.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2388360

Received on 2009-08-28 21:37:39 CEST

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.