On Thu 2004-09-16 at 19:33:35 -0400, Eric S. Raymond wrote:
> 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.
Not really. There are things this approach handles better then a local
svn repository (e.g. easily disabling some of the patches again,
refactoring a patch after WC updating, and so on). Yes, those things
are also relatively easy done with a changeset oriented VC, but for
keeping my sources, I prefer the Subversion approach. It's just for
the work before commiting, I like a bit more flexibility than I have
today (with svk having a MS Windows port, I have to have a new look at
it).
> When you say "would behave like a very limited local repository"
> alarm bells go off in my head.
Well, that was only a side-comment to clarify my meaning.
> I know immediately I'm going to run up against those limits.
Really? How? Wanting to know more about that was what made me write my
email to begin with. I don't mean to say you wouldn't run against
those limits. It's just that I don't recall anybody, who asked for a
local repository, present a use case in the Subversion context that
wouldn't be solved by such a "patch management". (and I mean a real
use case, something one already stumbled upon, not a theoretical one).
> For example, how do I save log text with my local patches?
Okay, I always referred to action diffs, but I see no reason not to
store a history diff instead. I already implied that one should name
the checkpoint, there is no reason not to ask for log message, too.
But probably it would be more useful to handle the log message similar
to a property, so that it's easy editable.
But to be honest, I didn't plan out the idea to such a detail yet.
> How do I group them into change sets, if I'm working on more than
> one independent bug or feature?
I am not sure what you mean here. How would you group the changes if
if you had online access and would commit directly to the main
repository? Maybe if you give an example of that, I can understand
better (in other words: which other groups than commits are there?)
Or maybe you mean, how do you declare two patches to be one? Well, the
same way you would do now for a commit: apply both patches. And I
wouldn't expect the mechanism to be much different to the way you
would do with manual patch management: Either single out the one patch
you want to edit, apply it to the WC, edit, then save an updated
patch. Or do your changes, realize that it is an update to another
patch, apply the that patch over the changes you already made in the
WC and save the updated patch.
Okay, it gets a bit complex, once one wants to update older patches
and the update creates a conflict with newer patches. But that is a
conflict you would have to solve anyhow before commiting. So it's not
really a new class of problems.
> 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.
No, it wouldn't feel like a local repo. A repository preserves
history. These checkpoints wouldn't (if you change a change, you lost
your former change), because I would want to keep them simple. And it
would especially not feel like a Subversion repository. Rather, it
would similar to changeset oriented VCs, like darcs or monotone (no
comparison to bitkeeper, because I don't know it well enough).
But real changesets do much more than I need (btw, that's why I
explicitly avoided to mention changesets until now). And they are much
more complex to implement. That's why I call it support for patch
management. You can already do most of it by hand. It's just support
for doing it easier (and especially of the svn commands being aware of
'finished' changes, so that you can run "svn diff" and have it ignore
some of your already made patches).
[...]
> > 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.
I was aware of that. But remember my words the first time you "just"
want to do an quick rsync of something like the emacs tree on your new
(and empty) notebook before heading to a train.
Your example needs a complete copy. Rsync only speeds it up as much as
your existing copy is recent. But yes, usually the speed-up will be
significant. But the unusual cases might hurt quite a bit.
Note that the process itself isn't quite as simple as it looks at
first glance, if you use the BDB-backend:
With BDB you have to:
1. Make sure no program accesses the local copy.
2. Pay attention to the sync order (logs last, see hotcopy tool for an
explanation).
3. Do a recover on the local copy in order to assure a consistent state.
4. (allow access again)
Reasonable scriptable, but not simple.
> > 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.
Ah, okay, if you see a solution on the horizon, then that point is moot.
> > - 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.
Hm. So you need to tell Subversion what your branching policy is.
Doesn't exist (currently Subversion has no clue which part of your
tree is considered a branch), but shouldn't be too hard to do.
Although I have no concrete reason against the idea of automatic
branch creation in this context, the idea that after week-ends or
similar events, the repository sees a lot of automatic branches which
will live only for some minutes (until they are no longer needed),
scares me a bit.
Sounds as much like a kluge to me like pseudo local repos. *eg*
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).
Bye,
Benjamin.
---------------------------------------------------------------------
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:00:07 2004