[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 00:49:16 CEST

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

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

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

- 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.



[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

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.