On Thu 2004-09-16 at 16:34:46 -0400, Eric S. Raymond wrote:
[...]
> Yup. svk, your scripts, various kluges with rsync, Tom Lord's
> attempts to start a conversation way back when. I'm not under any
> illusion that I was first in with this.
What you described as your use case, can IMHO also be solved by "svn
supported patch management". So out of curiosity: Is there something
additional to your use case that needs history diffs, or would the
following solution also work for you?
Let me explain: I know a similar situation like you and cmpilato,
namely, when I want to write patches for a project where I don't have
write-access for the repository (like Subversion itself, the few times
I send in patches). Quite often I end up having several parallel,
independend changes in my WC.
My usual handling of such a situation is to create patches with svn
diff, save them, and reverse apply them to the WC, before I change to
the next change. This currently fails on two points:
1. svn diff loses some of the changes (properties, move, and so on).
2. it's quite a pain to manually handle large amount of patches.
Point 1 will be solved when action diffs are introduced. So if there
was a solution for 2., most of my needs would be solved. As I
understand, it would also solve cmpilato's use case, and yours. Am I
correct?
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.
There is also a problem with my checkpoint suggestion: It needs
changes to the WC lib and most people agree not the implement new
features to that before a rewrite happened. On the other hand, my
suggestion reuses a lot of what is already in the lib.
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.
Such a feature is best, when you can simply continue where you left
off, when you still had repository access - without doing anything
special. (If I understood correctly, cmpilato's procedure works this
way, because he produces the local repository by checking in his
WC... which sounds quite hackish to me ;)
- 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.
Well, hope that idea wasn't obvious to everybody already.
Bye,
Benjamin.
[1] E.g. "svn diff" would show only newer changes and so on. I am not
sure of the details, but this would probably need to update the
text-bases with the change. Since an action diff should be
reversible (like a normal diff), there should be no problem to
revert such a change and get back a WC to the prestine state.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 17 00:49:31 2004