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).
Bye,
Benjamin.
[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
development)
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