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

Re: Eric goes to lunch -- a decentralized-development user story

From: Benjamin Pflugmann <benjamin-svn-dev_at_pflugmann.de>
Date: 2004-09-17 03:50:13 CEST

On Fri 2004-09-17 at 02:59:50 +0200, Benjamin wrote:
> But to come back to my original question: If you see a reason why a
> more or less sophisticated patch management support wouldn't suffice
> for you, I would love to hear it (more than any specific critic to the
> details of implementation I just have come up with).

One more thing: I wouldn't have a problem with the patch management[1]
using a local repository for storing and diff'ing its stuff. It's just
that a local repo doesn't automatically offer what I understand as
patch management support[2]

My suggestion came from the background that I think doing local repo
support _well_ is harder than the patch management I suggested. If
that premise is wrong, my point is moot (because a local repo offers
more flexibility, I think).



[1] Since I am throwing that expression around, I thought I do a
    little clarification. I haven't thought this out fully and am not
    sure that I can come up with a complete list, but what I would
    expect at least is:

    1. easy saving of patches (for re-applying or commiting)
    2. easy editing of patches (can be via an apply-edit-save cycle)
    3. easy overview of pending patches
    4. easy commiting of patches (ideally, if there are no conflicts, all
       local changes are committed in one pass)
    5. easy discarding of patches
    6. easy updates (in order to commit or keep current with parallel
    7. easy way to export patches (in order to send them in per email)

    AFAICS, a local repo, without further integration, mainly lacks
    for doing #2, #5 and #6.

[2] Although it would be doable to do integration in a way that it is
    equally useful for patch management. Eric, your "svn sync"
    suggestion already goes in that direction.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 03:50:52 2004

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.