Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de>:
> As I see it, a solution to "2." would be some "patch management". If I
> could checkpoint the WC, so that svn automatically saves an internal
> (action) diff (under some given name), and then the working copy
> behaves as if I checked in that change[1], creating several patches
> would be a lot easier.
>
> In some way that would behave like a very limited local repository.
> But in my case, such a limited feature would be probably enough. Of
> course a plus would be, if there was some easy way to enable/disable
> such checkpoints on the WC, without actually removing them.
>
> Then a checkin to an (updated) repository could become something like:
> disable all checkpoints, svn up, re-enable checkpoint 1, resolve
> conflicts if needed, commit, re-enable checkpoint 2, ... rinse and
> repeat.
It's an interesting idea, and in theory it might address the "Eric
goes to lunch" case.
The problem I have with it is that it proliferates mechanisms that are
meant to accomplish the same thing rather than adding one clean new
primitive notion. When you say "would behave like a very limited
local repository" alarm bells go off in my head. I know immediately
I'm going to run up against those limits.
For example, how do I save log text with my local patches? How do I group
them into change sets, if I'm working on more than one independent
bug or feature?
If it's going to walk like a local repo and quack like a local repo, I
feel very strongly that it ought to *be* a local repo. Otherwise
we'll just be inviting headaches at the places where these overlapping
mechanisms rub together.
(This is part of the reason I'm dubious about svk. It appears to me
to be guilty of the same sin.)
> I presented this idea, because I see some reasons against history
> diffs:
>
> - Your example (rsync) needs a complete copy of the repository.
> Although that can be reduced to syncing only the last revision with
> some scripting (dump only HEAD, sync the dump file, load the local
> repository with it), you have to know beforehand that you will work
> offline and prepare.
No, it's actually easier than that. You just treat the repo as a
blob and rsync it. Only the changed bits have to come down the wire.
> Such a feature is best, when you can simply continue where you left
> off, when you still had repository access - without doing anything
> special.
I agree. I have some vague ideas about how to accomplish this
involving introducing a new notion, that of a repo search path.
But I'm not ready to write about that yet, it's not even half baked.
> - In case the main repository has received updates other than yours,
> merging is needed and there is potential for conflicts. Although you
> suggested some policies how to handle them, you cannot avoid a human
> to be involved in conflict resolving sooner or later. Such resolving
> currently happens in the working copy, so why not start the merge in
> the WC to begin with? If there are no conflicts, patching and
> commiting is a no-brainer, too.
Reasonable point. My current thinking is that if a history diff does not
apply clean, it creates a new branch. Then you get to svn merge to resolve
the branch differences from trunk or whatever.
--
Eric S. Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 01:34:00 2004