On Mon, 23 Aug 2010, Simon Marlow wrote:
On 20/08/2010 13:40, Sittampalam, Ganesh wrote:
Simon Marlow wrote:
I'd be quite happy with a UI that did something like:
$ darcs pull
...
There are N patches to pull that conflict with M patches in your repository.
[P]ull anyway, and resolve conflicts later
[S]uspend the local conflicting patches, and rebase later
S[k]ip the conflicting patches, just pull the others
S[h]ow me the patches that are in conflict
[Q]uit, pulling no patches at all
?
and the chatty UI would be disabled if you give an explicit option such as
--skip-conflicts or --allow-conflicts.
OK, thanks. I need to keep thinking about this one, I think, and there's a
general redesign of the conflict acceptance UI implied here too.
What happens if you don't say 'y' to suspend all the patches that you
are presented with, during 'darcs rebase pull'? Would it be possible
to recover from doing that by accident?
Assuming you've got beyond the point where you can just ^C, you can
unpull all the patches that were pulled in and the redo the 'rebase
pull', and it'll offer any unsuspended patches again. Not exactly
friendly, though. If you can remember what they were, you could also
manually suspend the patches that you previously said 'n' to with
'rebase suspend'. Any ideas on a nicer workflow?
I suppose my question is more along the lines of "what state does it leave
your repository in, how can you tell what has happened, and how do you
recover?".
OK. This is connected to better information around conflicts, I guess -
i.e. being able to tell what is actually in conflict.
'rebase pull' is a bit slow: about 15s to completion after asking
which patches to suspend.
Is that any slower than it would have been if you'd instead unpulled the
patches that needed to be suspended and done a normal pull?
pulling a few patches takes less than 2 seconds, unpulling takes about 3-4
seconds with 2.4.98. This is on NFS. It's certainly faster with 2.4.98 than
it used to be with 2.4.4, but not the 0.1s I was hoping for. The 15s to
suspend patches does seem a lot slower than I expected, but then these were
quite large patches I suppose.
OK, so clearly room for improvement, but it's probably explained by
needing to build and write the suspended patch. Is that sort of order of
magnitude performance ok, or should I make improving it a priority?
Ganesh
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
