support for bzr shelve/unshelve in vc-dir

support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Are the bzr shelve/unshelve commands popular?

Do we want something similar to the vc-dir support for "git stash" for
bzr shelve/unshelve?

If yes, I can try to whip up a patch before the feature freeze...

Re: support for bzr shelve/unshelve in vc-dir

[Xavier Maillard]

   Are the bzr shelve/unshelve commands popular?

   Do we want something similar to the vc-dir support for "git stash" for
   bzr shelve/unshelve?

   If yes, I can try to whip up a patch before the feature freeze...

Speaking for myself, I'd vote for this feature.


	Xavier
-- 
http://www.gnu.org
http://www.april.org
http://www.lolica.org

Re: support for bzr shelve/unshelve in vc-dir

[Stefan Monnier]

> Are the bzr shelve/unshelve commands popular?
> Do we want something similar to the vc-dir support for "git stash" for
> bzr shelve/unshelve?

That would be welcome, yes.

> If yes, I can try to whip up a patch before the feature freeze...

There's no hurry on my side.  I'm probably more eager to see support for
things like pull/push.


        Stefan

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>> If yes, I can try to whip up a patch before the feature freeze...
>
> There's no hurry on my side.  I'm probably more eager to see support for
> things like pull/push.

... and `merge'

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> There's no hurry on my side.  I'm probably more eager to see support for
>> things like pull/push.
>
> ... and `merge'

oh, and `missing' too.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Óscar Fuentes <ofv@wanadoo.es> writes:
  > 
  > >> There's no hurry on my side.  I'm probably more eager to see support for
  > >> things like pull/push.
  > >
  > > ... and `merge'
  > 
  > oh, and `missing' too.

That's easy.  It can be directly derived from vc-outgoing, whenever I
manage to check it in.

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > If yes, I can try to whip up a patch before the feature freeze...
  > 
  > There's no hurry on my side.  I'm probably more eager to see support for
  > things like pull/push.

The "no problem" case for those is easy, just run the corresponding
command.
If someone does the design for those, I can help with the implementation.

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Stefan Monnier <monnier@IRO.UMontreal.CA> writes:
>
>   > > If yes, I can try to whip up a patch before the feature freeze...
>   > 
>   > There's no hurry on my side.  I'm probably more eager to see support for
>   > things like pull/push.
>
> The "no problem" case for those is easy, just run the corresponding
> command.
> If someone does the design for those, I can help with the implementation.

Being vc/vc-dir, I guess that the design must cover all dominant dVCS
today (git, mercurial, bazaar). I remember just a bit about git, and
know nothing about mercurial but, for the case of bazaar, adding basic
support for pull/push/merge seems fairly easy: execute the command,
report the result and refresh the displayed VC info.

One extra goodie that is not too hard to implement is to support an
invocation mode where the user can provide an alternative location (C-u
perhaps?). IIRC you must provide a location when you invoke push/merge
for the first time on Bazaar, so detecting and handling this condition
may be a bit tricky. Providing a location would be useful for `diff'
too, for showing the differences among two branches.

A system for storing named bookmarks (locations) so you are not forced
to write the same cumbersome URLs again and again and use names instead
would be very handy. I don't know how much work this requires.

Finally, implementing invocation parameters for supporting all the
useful variants 'merge' has seems a bit daunting to integrate on the
current interface and maybe warrants using a specific buffer where you
can preview what's available for merging (retrieved with `missing' or
with `diff') and then choose how to perform the operarion. This seems
very backend-dependent and a lot of work, but would add a lot of value
to vc/vc-dir.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Stefan Monnier]

> may be a bit tricky. Providing a location would be useful for `diff'
> too, for showing the differences among two branches.

C-u C-v x = does allow you to specify a branch.

> A system for storing named bookmarks (locations) so you are not forced
> to write the same cumbersome URLs again and again and use names instead
> would be very handy. I don't know how much work this requires.

This really belongs in `bzr' in my opinion.  `git' is a lot better in
this respect.

> Finally, implementing invocation parameters for supporting all the
> useful variants 'merge' has seems a bit daunting to integrate on the

Not sure what you're referring to here.


        Stefan

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> may be a bit tricky. Providing a location would be useful for `diff'
>> too, for showing the differences among two branches.
>
> C-u C-v x = does allow you to specify a branch.

Thanks.

[snip]

>> Finally, implementing invocation parameters for supporting all the
>> useful variants 'merge' has seems a bit daunting to integrate on the
>
> Not sure what you're referring to here.

Execute

bzr help merge

some options listed there are really useful and it would be nice to use
them from vc.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Xavier Maillard <xma@gnu.org> writes:

  >    Are the bzr shelve/unshelve commands popular?
  > 
  >    Do we want something similar to the vc-dir support for "git stash" for
  >    bzr shelve/unshelve?
  > 
  >    If yes, I can try to whip up a patch before the feature freeze...
  > 
  > Speaking for myself, I'd vote for this feature.

Here's a quick port of the git code (It still uses the "stash" name).
It can create and remove shelves.
I don't see a way to display the diff for a shelf.


Index: vc-bzr.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/vc-bzr.el,v
retrieving revision 1.86
diff -u -3 -p -u -p -r1.86 vc-bzr.el
--- vc-bzr.el	26 Nov 2009 14:50:32 -0000	1.86
+++ vc-bzr.el	2 Dec 2009 05:25:45 -0000
@@ -703,11 +705,33 @@ stream.  Standard error output is discar
   (vc-exec-after
    `(vc-bzr-after-dir-status (quote ,update-function))))
 
+(defvar vc-bzr-stash-map
+  (let ((map (make-sparse-keymap)))
+    (define-key map "\C-k" 'vc-bzr-stash-delete-at-point)
+    (define-key map "=" 'vc-bzr-stash-show-at-point)
+    (define-key map "\C-m" 'vc-bzr-stash-show-at-point)
+    map))
+
+(defvar vc-bzr-extra-menu-map
+  (let ((map (make-sparse-keymap)))
+    (define-key map [bzr-st]
+      '(menu-item "Stash..." vc-bzr-stash
+		  :help "Stash away changes"))
+    (define-key map [bzr-ss]
+      '(menu-item "Show Stash..." vc-bzr-stash-show
+		  :help "Show stash contents"))
+    map))
+
+(defun vc-bzr-extra-menu () vc-bzr-extra-menu-map)
+
+(defun vc-bzr-extra-status-menu () vc-bzr-extra-menu-map)
+
 (defun vc-bzr-dir-extra-headers (dir)
   (let*
       ((str (with-temp-buffer
 	      (vc-bzr-command "info" t 0 dir)
 	      (buffer-string)))
+       (stash (vc-bzr-stash-list))
        (light-checkout
 	(when (string-match ".+light checkout root: \\(.+\\)$" str)
 	  (match-string 1 str)))
@@ -721,18 +745,81 @@ stream.  Standard error output is discar
       (if (string-match "parent branch: \\(.+\\)$" str)
  	  (match-string 1 str)
  	"None")
-       'face 'font-lock-variable-name-face)
+      'face 'font-lock-variable-name-face)
      "\n"
-      (when light-checkout
-	(concat
-	 (propertize "Light checkout root: " 'face 'font-lock-type-face)
-	 (propertize light-checkout 'face 'font-lock-variable-name-face)
-	 "\n"))
-      (when light-checkout-branch
-	(concat
-	 (propertize "Checkout of branch : " 'face 'font-lock-type-face)
-	 (propertize light-checkout-branch 'face 'font-lock-variable-name-face)
-	 "\n")))))
+     (when light-checkout
+       (concat
+	(propertize "Light checkout root: " 'face 'font-lock-type-face)
+	(propertize light-checkout 'face 'font-lock-variable-name-face)
+	"\n"))
+     (when light-checkout-branch
+       (concat
+	(propertize "Checkout of branch : " 'face 'font-lock-type-face)
+	(propertize light-checkout-branch 'face 'font-lock-variable-name-face)
+	"\n"))
+     (if stash
+	 (concat
+	  (propertize "Stash      :\n" 'face 'font-lock-type-face)
+	  (mapconcat
+	   (lambda (x)
+	     (propertize x
+			 'face 'font-lock-variable-name-face
+			 'mouse-face 'highlight
+			 'keymap vc-bzr-stash-map))
+	   stash "\n"))
+       (concat
+	(propertize "Stash      : " 'face 'font-lock-type-face)
+	(propertize "Nothing stashed"
+		    'face 'font-lock-variable-name-face))))))
+
+
+(defun vc-bzr-stash (name)
+  "Create a stash."
+  (interactive "sStash name: ")
+  (let ((root (vc-bzr-root default-directory)))
+    (when root
+      (vc-bzr-command "shelve" nil 0 nil "--all" "-m" name)
+      (vc-resynch-buffer root t t))))
+
+(defun vc-bzr-stash-show (name)
+  "Show the contents of stash NAME."
+  (interactive "sStash name: ")
+  (vc-setup-buffer "*vc-bzr-stash*")
+  ;; FIXME: how can you show the contents of a shelf?
+  (vc-bzr-command "shelve" "*vc-bzr-stash*" 'async nil name)
+  (set-buffer "*vc-bzr-stash*")
+  (diff-mode)
+  (setq buffer-read-only t)
+  (pop-to-buffer (current-buffer)))
+
+(defun vc-bzr-stash-list ()
+  (with-temp-buffer
+    (vc-bzr-command "shelve" (current-buffer) 1 nil "--list")
+    (delete
+     ""
+     (split-string
+      (buffer-substring (point-min) (point-max))
+      "\n"))))
+
+(defun vc-bzr-stash-get-at-point (point)
+  (save-excursion
+    (goto-char point)
+    (beginning-of-line)
+    (if (looking-at "^ +\\([0-9]+\\):")
+	(match-string 1)
+      (error "Cannot find stash at point"))))
+
+(defun vc-bzr-stash-delete-at-point ()
+  (interactive)
+  (let ((stash (vc-bzr-stash-get-at-point (point))))
+    (when (y-or-n-p (format "Remove stash %s ?" stash))
+      (vc-bzr-command "unshelve" nil 0 nil "--delete-only" stash)
+      (vc-dir-refresh))))
+
+(defun vc-bzr-stash-show-at-point ()
+  (interactive)
+  (vc-bzr-stash-show (vc-bzr-stash-get-at-point (point))))
+
 
 ;;; Revision completion
 

Re: support for bzr shelve/unshelve in vc-dir

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > A system for storing named bookmarks (locations) so you are not forced
 > > to write the same cumbersome URLs again and again and use names instead
 > > would be very handy. I don't know how much work this requires.
 > 
 > This really belongs in `bzr' in my opinion.  `git' is a lot better in
 > this respect.

Doesn't bzr's branch nickname feature serve here?  If it does, it has
the advantage that names you use in Emacs will also serve in the
shell.

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> I don't see a way to display the diff for a shelf.

`shelf1' does a lot of operations with shelves:

bzr help shelf1

That command is from the bzrtools plugin, which is not guaranteed to be
installed along with bzr, although is probably the most popular and
considered a "must have".

[snip]

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Stefan Monnier writes:
>
>  > > A system for storing named bookmarks (locations) so you are not forced
>  > > to write the same cumbersome URLs again and again and use names instead
>  > > would be very handy. I don't know how much work this requires.
>  > 
>  > This really belongs in `bzr' in my opinion.  `git' is a lot better in
>  > this respect.
>
> Doesn't bzr's branch nickname feature serve here?

Not really. Bazaar has no problems working with multiple branches with
the same nick and, unless you explicitly name them with `bzr nick
<name>', the nick will be the same as the parent's. OTOH, the nick
doesn't tell bazaar the location of the branch.

AFAIK, git has a bookmark system built-in. There is a plugin for bazaar,
but I don't know how well it works.

[snip]

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

  > > Are the bzr shelve/unshelve commands popular?
  > > Do we want something similar to the vc-dir support for "git stash" for
  > > bzr shelve/unshelve?
  > 
  > That would be welcome, yes.

Done.
I couldn't find a way to display the content of a shelf, so support for
that is missing.

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > > Are the bzr shelve/unshelve commands popular?  Do we want
>   > > something similar to the vc-dir support for "git stash" for bzr
>   > > shelve/unshelve?
>   > 
>   > That would be welcome, yes.
>
> Done.

The implementation shelves all the changes on the current
branch. Although this is useful, an usual application of `shelve' is for
temporarily removing out of your way some changes (allowing to commit
only specific changes of the edited files, for example.) An ideal
implementation of `shelve' for vc would show the output of `bzr diff',
mark the hunks you want to shelve, and then run the command. Sadly, it
seems impossible to non-interactively indicate to bzr which hunks it
should shelve.

> I couldn't find a way to display the content of a shelf, so support for
> that is missing.

As mentioned on a previous message, `bzr shelf1 list' should do what you
need. It is from bzrtools, which is a popular plugin. However, the
command either is broken or I don't know how to use it. I'll ask on the
bazaar ml.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Bojan Nikolic]

Óscar Fuentes <ofv@wanadoo.es> writes:

> As mentioned on a previous message, `bzr shelf1 list' should do what you
> need. It is from bzrtools, which is a popular plugin. However, the
> command either is broken or I don't know how to use it. I'll ask on the
> bazaar ml.

I think:

  bzr shelve --list

should do the trick and it is in the core bzr package.

Best,
Bojan

-- 
Bojan Nikolic          ||          http://www.bnikolic.co.uk

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >   > > Are the bzr shelve/unshelve commands popular?  Do we want
  > >   > > something similar to the vc-dir support for "git stash" for bzr
  > >   > > shelve/unshelve?
  > >   > 
  > >   > That would be welcome, yes.
  > >
  > > Done.
  > 
  > The implementation shelves all the changes on the current
  > branch. Although this is useful, an usual application of `shelve' is for
  > temporarily removing out of your way some changes (allowing to commit
  > only specific changes of the edited files, for example.) An ideal
  > implementation of `shelve' for vc would show the output of `bzr diff',
  > mark the hunks you want to shelve, and then run the command. Sadly, it
  > seems impossible to non-interactively indicate to bzr which hunks it
  > should shelve.

That's exactly the reason for the current implementation.
Patches to add other methods to create shelves (including an
interactive) are surely welcome.

  > > I couldn't find a way to display the content of a shelf, so support for
  > > that is missing.
  > 
  > As mentioned on a previous message, `bzr shelf1 list' should do what you
  > need. It is from bzrtools, which is a popular plugin. However, the
  > command either is broken or I don't know how to use it. I'll ask on the
  > bazaar ml.

bzr shelf1 list doesn't even show shelves created with bzr shelve...

Splitting changes (was: support for bzr shelve/unshelve in vc-dir)

[Stefan Monnier]

>> The implementation shelves all the changes on the current
>> branch. Although this is useful, an usual application of `shelve' is for
>> temporarily removing out of your way some changes (allowing to commit
>> only specific changes of the edited files, for example.) An ideal
>> implementation of `shelve' for vc would show the output of `bzr diff',
>> mark the hunks you want to shelve, and then run the command. Sadly, it
>> seems impossible to non-interactively indicate to bzr which hunks it
>> should shelve.

> That's exactly the reason for the current implementation.
> Patches to add other methods to create shelves (including an
> interactive) are surely welcome.

I've been interested in this issue for a while now: I've been using
a local patch to VC which adds a command
"vc-prepare-for-partial-commit", which allows to choose which part of
some local changes should be committed and which part should be kept
for later.

I've never installed it in the trunk for various reasons, but I've use
it extensively for many years.  In this time I noticed the following:
- selecting only by files is not a fine enough granularity.
- selecting only by hunks is sometimes sufficient, but even that is too
  coarse in my experience.  The typical problem is that I want to split
  a change into a cleanup part and an actual new feature, but in most
  cases all the cleanup changes touch the exact same code as the new
  feature, so many of the hunks mix both.

So the way my hack works is the following:
- it takes ("stashes") a copy of the current state.
- then it lets you make any changes you want (the intention is that
  you're going to revert the changes you want to keep for later).
  You can do this part at any granularity: files, hunks, or even
  by hand.
- when done, you commit, after which the saved files are re-instated.

This gives me great flexibility, and lets me use any tool I want to
select which parts to keep and which parts not.  So I really like it.
But it has some serious drawbacks:
- if the final commit fails because the tree is not uptodate (any more),
  the backend won't know that the update should apply to both the file
  and its "stashed" copy.  So you end up having to deal with updates
  missing from the stashed copy, or abort the partial commit
  (i.e. revert to the stashed copy), then update, then re-do the split
  by hand.
- when doing the split by hand, you can make any change you want.
  The intention is for those changes to "undo" part of the local
  changes, but nothing prevents you from adding new changes during this
  time (as you revisit the code to choose how to split your changes, you
  may bump into new opportunities for cleanup and it's sometimes
  difficult to refrain from doing them at that point).  And if you do
  add local changes, then these will be undone after commit when the
  saved files are re-instated.

So I'd like VC to support something like that, but in a way that is
a bit more robust.  The way I see it working ideally is something like
the following:
- the copy is taken by committing the local changes on a new temporary branch
  (IIUC, that's pretty much what "git stash" does).
- then revert to the original branch and reapply those same changes
  (without committing them).
- at this point the user can use any tool he likes to remove parts of
  those changes he doesn't want to commit yet.  She can also "update"
  her tree when needed.
- when she's ready, she can perform the "commit", after which VC will
  ask to merge the temporary branch (without committing the result),
  which will hopefully result in pretty much the same as the original
  code before this whle partial commit took place.

The advantage here, is that because we use branches rather than manually
copying files behind the VCS's back, the VCS has all the needed
meta-data to ensure that no change is accidentally lost or undone.

The disadvantage is that the final merge is likely to introduce spurious
conflicts since it will re-apply the parts of the changes that
were just committed.  But if "same change conflicts" are automatically
resolved by your merge tool, then all the changes that were selected at
the granularity of a hunk (or larger) should be merged
without conflict.  I.e. you should only see conflicts when you actually
take advantage of the extra flexibility.


        Stefan

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

[snip]

>   > > I couldn't find a way to display the content of a shelf, so support for
>   > > that is missing.
>   > 
>   > As mentioned on a previous message, `bzr shelf1 list' should do what you
>   > need. It is from bzrtools, which is a popular plugin. However, the
>   > command either is broken or I don't know how to use it. I'll ask on the
>   > bazaar ml.
>
> bzr shelf1 list doesn't even show shelves created with bzr shelve...

Someone told me that bzrtools' `shelf1' only works with bzrtools'
`shelve1'. It is incompatible with with bzr's `shelve'. For looking at
the changes on a shelve1, you need `bzr shelf1 list', which lists the
patches, and `bzr shelf1 show PATCH', which actually shows the patch:

scar@qcore:~/dev/other/bzr-emacs/trunk$ bzr shelve1 --all
Shelving to 1/00: "Changes shelved on 2009-12-03 18:12:08"

oscar@qcore:~/dev/other/bzr-emacs/trunk$ bzr shelf1 list
Patches on shelf '1':                                   
 00: Changes shelved on 2009-12-03 18:12:08             

oscar@qcore:~/dev/other/bzr-emacs/trunk$ bzr shelf1 show 00
# Shelved patch: Changes shelved on 2009-12-03 18:12:08
--- INSTALL     2009-09-13 22:15:10 +0000
+++ INSTALL     2009-12-03 17:12:01 +0000
@@ -811,3 +811,4 @@

 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
+foo
--- README      2009-06-21 04:46:07 +0000
+++ README      2009-12-03 17:12:01 +0000
@@ -107,3 +107,4 @@

 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.
+zoo

Re: Splitting changes (was: support for bzr shelve/unshelve in vc-dir)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Thu, 03 Dec 2009 12:05:49 -0500
> Cc: =?iso-8859-1?Q?=D3scar?= Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> I've been interested in this issue for a while now: I've been using
> a local patch to VC which adds a command
> "vc-prepare-for-partial-commit", which allows to choose which part of
> some local changes should be committed and which part should be kept
> for later.

Sounds like you want to clone the current branch, make some changes
there, commit those changes upstream, then merge them with your
original branch and return there for more hacking.  Is that right?  If
so, why do we need a VC feature for that -- don't modern VCS support
such a workflow already?

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Óscar Fuentes <ofv@wanadoo.es> writes:

>> bzr shelf1 list doesn't even show shelves created with bzr shelve...
>
> Someone told me that bzrtools' `shelf1' only works with bzrtools'
> `shelve1'. It is incompatible with with bzr's `shelve'.
[snip]

Further discussion on the bazaar ml indicates that using shelve1/shelf1
is not a good idea.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Óscar Fuentes <ofv@wanadoo.es> writes:
  > 
  > >> bzr shelf1 list doesn't even show shelves created with bzr shelve...
  > >
  > > Someone told me that bzrtools' `shelf1' only works with bzrtools'
  > > `shelve1'. It is incompatible with with bzr's `shelve'.
  > [snip]
  > 
  > Further discussion on the bazaar ml indicates that using shelve1/shelf1
  > is not a good idea.

Can you please forward 2 feature requests for shelve/unshelve then:
1. some way to show the diff
2. something similar to "git stash apply", i.e. apply the shelf but do
not remove it.  This makes it easy to split changes for example.

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > Further discussion on the bazaar ml indicates that using shelve1/shelf1
>   > is not a good idea.
>
> Can you please forward 2 feature requests for shelve/unshelve then:
> 1. some way to show the diff

This is underway.

> 2. something similar to "git stash apply", i.e. apply the shelf but do
> not remove it.  This makes it easy to split changes for example.

Would you care to describe a plausible scenario where this is useful?
I can't think of one rigth now.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >   > Further discussion on the bazaar ml indicates that using shelve1/shelf1
  > >   > is not a good idea.
  > >
  > > Can you please forward 2 feature requests for shelve/unshelve then:
  > > 1. some way to show the diff
  > 
  > This is underway.

Good, code to support it is there, but commented out.

  > > 2. something similar to "git stash apply", i.e. apply the shelf but do
  > > not remove it.  This makes it easy to split changes for example.
  > 
  > Would you care to describe a plausible scenario where this is useful?
  > I can't think of one rigth now.

Say you have something shelved.
You want to try to refine the change, unshelve it and continue working
on it.  If you realize that what you had before was better, there's no
easy way to go back.
Or if you want to split a change: 
shelve
apply
remove the part you don't want
shelve the partial change
unshelve the original
remove some other part
shelve again

Re: Splitting changes

[Stefan Monnier]

>> I've been interested in this issue for a while now: I've been using
>> a local patch to VC which adds a command
>> "vc-prepare-for-partial-commit", which allows to choose which part of
>> some local changes should be committed and which part should be kept
>> for later.
> Sounds like you want to clone the current branch, make some changes
> there, commit those changes upstream, then merge them with your
> original branch and return there for more hacking.  Is that right?  If
> so, why do we need a VC feature for that -- don't modern VCS support
> such a workflow already?

I want that support right there in VC.


        Stefan

Re: Splitting changes

[Óscar Fuentes]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

[snip]

> So the way my hack works is the following:
> - it takes ("stashes") a copy of the current state.
> - then it lets you make any changes you want (the intention is that
>   you're going to revert the changes you want to keep for later).
>   You can do this part at any granularity: files, hunks, or even
>   by hand.
> - when done, you commit, after which the saved files are re-instated.

This can be achieved with the feature Dan is requesting for Bazaar (and
git already has):

  > > 2. something similar to "git stash apply", i.e. apply the shelf but do
  > > not remove it.  This makes it easy to split changes for example.

With that feature you would do

bzr shelve --all
bzr unshelve --keep  # that option would prevent removing the shelve
<hack, hack, hack>
bzr commit etc
bzr unshelve

> This gives me great flexibility, and lets me use any tool I want to
> select which parts to keep and which parts not.  So I really like it.
> But it has some serious drawbacks:
> - if the final commit fails because the tree is not uptodate (any more),
>   the backend won't know that the update should apply to both the file
>   and its "stashed" copy.  So you end up having to deal with updates
>   missing from the stashed copy, or abort the partial commit
>   (i.e. revert to the stashed copy), then update, then re-do the split
>   by hand.
>
> - when doing the split by hand, you can make any change you want.
>   The intention is for those changes to "undo" part of the local
>   changes, but nothing prevents you from adding new changes during this
>   time (as you revisit the code to choose how to split your changes, you
>   may bump into new opportunities for cleanup and it's sometimes
>   difficult to refrain from doing them at that point).  And if you do
>   add local changes, then these will be undone after commit when the
>   saved files are re-instated.

`bzr unshelve' merges the patch it contains, instead of blindly applying
it. It is enough for solving those problems?

[snip]

-- 
Óscar

Re: Splitting changes

[Stefan Monnier]

>> So the way my hack works is the following:
>> - it takes ("stashes") a copy of the current state.
>> - then it lets you make any changes you want (the intention is that
>> you're going to revert the changes you want to keep for later).
>> You can do this part at any granularity: files, hunks, or even
>> by hand.
>> - when done, you commit, after which the saved files are re-instated.

> This can be achieved with the feature Dan is requesting for Bazaar (and
> git already has):

>> > 2. something similar to "git stash apply", i.e. apply the shelf but do
>> > not remove it.  This makes it easy to split changes for example.

> With that feature you would do

> bzr shelve --all
> bzr unshelve --keep  # that option would prevent removing the shelve
> <hack, hack, hack>
> bzr commit etc
> bzr unshelve

Yes, that sounds about right.  IIUC "bzr unshelve --keep" is what Dan
calls "bzr apply".  So the fundamental backend operations that are
needed are shelve/stash (with a vc-fileset), unshelve-keep/apply, and
unshelve.  We could even provide a default implementation that "shelves"
by storing a patch, and unshelves by apply that patch, for those
backends that don't support anything similar.


        Stefan

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

>   > > Can you please forward 2 feature requests for shelve/unshelve then:
>   > > 1. some way to show the diff
>   > > 2. something similar to "git stash apply", i.e. apply the shelf but do
>   > > not remove it.  This makes it easy to split changes for example.

[snip]

Support for unshelve --keep :
https://bugs.launchpad.net/bzr/+bug/492095

Support for shelve -F :
https://bugs.launchpad.net/bzr/+bug/492091

For showing the contents of a shelve there are already 2 reports:

bzr unshelve --dry-run should produce a diff:
https://bugs.launchpad.net/bzr/+bug/317896

No reliable way to show shelved changes:
https://bugs.launchpad.net/bzr/+bug/308122

Don't hold your breath.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >   > > Can you please forward 2 feature requests for shelve/unshelve then:
  > >   > > 1. some way to show the diff
  > >   > > 2. something similar to "git stash apply", i.e. apply the shelf but do
  > >   > > not remove it.  This makes it easy to split changes for example.
  > 
  > [snip]
  > 
  > Support for unshelve --keep :
  > https://bugs.launchpad.net/bzr/+bug/492095

  > Support for shelve -F :
  > https://bugs.launchpad.net/bzr/+bug/492091
  > 
  > For showing the contents of a shelve there are already 2 reports:
  > 
  > bzr unshelve --dry-run should produce a diff:
  > https://bugs.launchpad.net/bzr/+bug/317896
  > 
  > No reliable way to show shelved changes:
  > https://bugs.launchpad.net/bzr/+bug/308122
  > 
  > Don't hold your breath.

I know nothing about bzr, but unshelve --keep is gotta be trivial to
implement... 

Re: support for bzr shelve/unshelve in vc-dir

[Stephen J. Turnbull]

Dan Nicolaescu writes:

 > I know nothing about bzr, but unshelve --keep is gotta be trivial to
 > implement... 

It's not, because the shelf is kept in the history.  Unshelving needs
to rewind the history so that tip points to the pre-shelve revision.
bzr has no refs, so recovering the shelved revision after an unshelve
is non-trivial.  It may not be hard, either, except that for it to be
reliable may require the bzr developers to make promises about internal
storage management.

Looms (requires an incompatible branch format) and pipelines (like
Mercurial queues or Stacked Git) provide the necessary scaffolding.

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

  > Dan Nicolaescu writes:
  > 
  >  > I know nothing about bzr, but unshelve --keep is gotta be trivial to
  >  > implement... 
  > 
  > It's not, because the shelf is kept in the history.  Unshelving needs
  > to rewind the history so that tip points to the pre-shelve revision.
  > bzr has no refs, so recovering the shelved revision after an unshelve
  > is non-trivial.  It may not be hard, either, except that for it to be
  > reliable may require the bzr developers to make promises about internal
  > storage management.

A several months old bzr tree happens to be my playground for testing
VC changes on bzr.
I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and
now "bzr unshelve --apply" does not remove shelves, and they seem to be
valid and can be applied multiple times.

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
>
>   > Dan Nicolaescu writes:
>   > 
>   >  > I know nothing about bzr, but unshelve --keep is gotta be trivial to
>   >  > implement... 
>   > 
>   > It's not, because the shelf is kept in the history.  Unshelving needs
>   > to rewind the history so that tip points to the pre-shelve revision.
>   > bzr has no refs, so recovering the shelved revision after an unshelve
>   > is non-trivial.  It may not be hard, either, except that for it to be
>   > reliable may require the bzr developers to make promises about internal
>   > storage management.
>
> A several months old bzr tree happens to be my playground for testing
> VC changes on bzr.
> I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and
> now "bzr unshelve --apply" does not remove shelves, and they seem to be
> valid and can be applied multiple times.

Exactly my findings.

As unshelve essentially does a merge, I do not understand why what
Stephen explains is relevant here. Furthermore, Bazaar allows having
multiple shelves and unshelving them out-of-order. But I'm not an expert
on this area either and possibly I'm missing something.

BTW, coding the feature is trivial. Getting it into Bazaar is the
difficult part. They have a slow, very stringent process for
incorporating changes. They require to sign copyright papers too,
something I did for Emacs but wont do for a private business.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > > I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and
 > > now "bzr unshelve --apply" does not remove shelves, and they seem to be
 > > valid and can be applied multiple times.
 > 
 > Exactly my findings.

Well, if it works, it works.  Good news!

I had thought that bzr's implementation was like git's, but apparently
it's more like a Mercurial queue.  I apologize for the misinformation.

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > "Stephen J. Turnbull" <stephen@xemacs.org> writes:
  > >
  > >   > Dan Nicolaescu writes:
  > >   > 
  > >   >  > I know nothing about bzr, but unshelve --keep is gotta be trivial to
  > >   >  > implement... 
  > >   > 
  > >   > It's not, because the shelf is kept in the history.  Unshelving needs
  > >   > to rewind the history so that tip points to the pre-shelve revision.
  > >   > bzr has no refs, so recovering the shelved revision after an unshelve
  > >   > is non-trivial.  It may not be hard, either, except that for it to be
  > >   > reliable may require the bzr developers to make promises about internal
  > >   > storage management.
  > >
  > > A several months old bzr tree happens to be my playground for testing
  > > VC changes on bzr.
  > > I changed "delete_shelf" to always be True in bzrlib/shelf_ui.py, and
  > > now "bzr unshelve --apply" does not remove shelves, and they seem to be
  > > valid and can be applied multiple times.
  > 
  > Exactly my findings.
  > 
  > As unshelve essentially does a merge, I do not understand why what
  > Stephen explains is relevant here. Furthermore, Bazaar allows having
  > multiple shelves and unshelving them out-of-order. But I'm not an expert
  > on this area either and possibly I'm missing something.
  > 
  > BTW, coding the feature is trivial. Getting it into Bazaar is the
  > difficult part. They have a slow, very stringent process for
  > incorporating changes. They require to sign copyright papers too,
  > something I did for Emacs but wont do for a private business.

Please don't give up.
The change quite likely would not require copyright assignment: it's
very small and it's probably the only way to implement the feature.

Re: support for bzr shelve/unshelve in vc-dir

[Óscar Fuentes]

Dan Nicolaescu <dann@ics.uci.edu> writes:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>   > BTW, coding the feature is trivial. Getting it into Bazaar is the
>   > difficult part. They have a slow, very stringent process for
>   > incorporating changes. They require to sign copyright papers too,
>   > something I did for Emacs but wont do for a private business.
>
> Please don't give up.
> The change quite likely would not require copyright assignment: it's
> very small and it's probably the only way to implement the feature.

They require copyright assignment even for one-liners.

Contributing to Bazaar is difficult, they know it, and the developers
are trying to alleviate the process. But in the end, Bazaar is a
Canonical product and its development is guided by Canonical's business
strategy.

-- 
Óscar

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Óscar Fuentes <ofv@wanadoo.es> writes:

  > Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > > Óscar Fuentes <ofv@wanadoo.es> writes:
  > >   > BTW, coding the feature is trivial. Getting it into Bazaar is the
  > >   > difficult part. They have a slow, very stringent process for
  > >   > incorporating changes. They require to sign copyright papers too,
  > >   > something I did for Emacs but wont do for a private business.
  > >
  > > Please don't give up.
  > > The change quite likely would not require copyright assignment: it's
  > > very small and it's probably the only way to implement the feature.
  > 
  > They require copyright assignment even for one-liners.

Bummer, then maybe just describe the change you did and say that it
works, that way someone else might be able to pick it up.
Maybe Karl Fogel can help with this...

Re: support for bzr shelve/unshelve in vc-dir

[Glenn Morris]

Óscar Fuentes wrote:

> Contributing to Bazaar is difficult, they know it, and the developers
> are trying to alleviate the process. But in the end, Bazaar is a
> Canonical product and its development is guided by Canonical's business
> strategy.

It's also a GNU project. People ought to be able to feel confident
about contributing to GNU projects. But when I had a quick look at the
conditions for becoming one:

http://www.gnu.org/help/evaluation.html

I couldn't immediately see anything that would alleviate your worries.
But, I'm not sure exactly what your worries are.


While reading the conditions on that page, a first glance at the bzr
2.0.2 source shows: it is distributed under GPLv2+ rather than v3+,
http://www.gnu.org/software/bzr does not exist, it does not have
texinfo documentation, it contains numerous references to the "Linux"
operating system, and there doesn't seem to be any reference in the
--version output or man-page to it being a GNU project.

Re: support for bzr shelve/unshelve in vc-dir

[Stephen J. Turnbull]

Glenn Morris writes:

 > I couldn't immediately see anything that would alleviate your worries.
 > But, I'm not sure exactly what your worries are.

Simply that a patch will never be applied to the canonical Bazaar,
thus making better support for shelve in vc.el dependent on the user
having a patched bzr.

The Bazaar project has an extremely strict and centralized (!)
process, compared to which Emacs might well be considered an anarchy:
2 committers are required to approve each patch, and even the
assignment policy is stricter (all contributions to the core, no
matter how small, must be assigned -- third party plugins may remain
the property of the developer, though).

Until about three weeks ago, patches that didn't fit any of the
committers' agendas tended to languish in the queue.  They've long
recognized that this is a problem, and after dithering for a bit have
established a "patch pilot" program which is intended to guide 3rd
party patches through the process.  So far (less than a month of
experience, but it's indicative) it's been very successful in getting
doc and minor improvements through.  However, changes in UI still tend
to get stuck (for everybody, including the core committers) in
bikeshedding.

 > While reading the conditions on that page, a first glance at the bzr
 > 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+,
 > http://www.gnu.org/software/bzr does not exist, it does not have
 > texinfo documentation, it contains numerous references to the "Linux"
 > operating system, and there doesn't seem to be any reference in the
 > --version output or man-page to it being a GNU project.

Nope, and Canonical management is pushing in the direction of
emphasizing that it's a *Canonical product*: eg, all of the URLs are
moving from "bazaar-vcs.org" to "bazaar.canonical.com".  They got some
pushback from the peanut gallery, but no committers seem to have a
problem with that.

Re: support for bzr shelve/unshelve in vc-dir

[Jan Djärv]

Stephen J. Turnbull skrev:
> Glenn Morris writes:
> 
>  > While reading the conditions on that page, a first glance at the bzr
>  > 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+,
>  > http://www.gnu.org/software/bzr does not exist, it does not have
>  > texinfo documentation, it contains numerous references to the "Linux"
>  > operating system, and there doesn't seem to be any reference in the
>  > --version output or man-page to it being a GNU project.
> 
> Nope, and Canonical management is pushing in the direction of
> emphasizing that it's a *Canonical product*: eg, all of the URLs are
> moving from "bazaar-vcs.org" to "bazaar.canonical.com".  They got some
> pushback from the peanut gallery, but no committers seem to have a
> problem with that.
> 

Does this mean that bazaar is no longer preferred, as the reason for that was 
that it was a GNU project?  Can we now go for git instead? :-).

	Jan D.

Re: support for bzr shelve/unshelve in vc-dir

[Miles Bader]

Jan Djärv <jan.h.d@swipnet.se> writes:
> Does this mean that bazaar is no longer preferred, as the reason for
> that was that it was a GNU project?  Can we now go for git instead? :-).

It's still technically a GNU project AFAIK... though I'm surprised to
hear canonical requires copyright assignment to themselves -- I sort of
thought official GNU projects were all copyright FSF?

[This sort of talk does tend to reinforce doubts I've always had about
canonical's motivations for making it a GNU project, but I'm not sure
what the practical effects of such practices are, other than being kind
of annoying.]

-Miles

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: support for bzr shelve/unshelve in vc-dir

[Stephen J. Turnbull]

Jan Djärv writes:

 > Does this mean that bazaar is no longer preferred, as the reason
 > for that was that it was a GNU project?

Nothing has changed.  The situation was acceptable then, why wouldn't
it be now?

 > Can we now go for git instead? :-).

You've always been able to go for git instead.  It's a little bit
annoying to manage a bidirectional gateway, but well worth it IM very
personal O.

To repeat: I don't recommend that for everybody, that's just the way I
like it.  And dVCS means I can dance to my own drumbeat, thank you
very much!

Re: support for bzr shelve/unshelve in vc-dir

[Stefan Monnier]

> It's still technically a GNU project AFAIK... though I'm surprised to
> hear canonical requires copyright assignment to themselves -- I sort of
> thought official GNU projects were all copyright FSF?

No, some GNU packages require an FSF copyright assignment, but others
don't require any assignment at all.  The guidelines for being a GNU
package are fairly loose,


        Stefan

Re: support for bzr shelve/unshelve in vc-dir

[Glenn Morris]

Glenn Morris wrote:

> http://www.gnu.org/software/bzr does not exist

http://www.gnu.org/software/bazaar exists, as a redirect.
I should have checked properly.

Re: support for bzr shelve/unshelve in vc-dir

[Richard Stallman]

    texinfo documentation, it contains numerous references to the "Linux"
    operating system, and there doesn't seem to be any reference in the
    --version output or man-page to it being a GNU project.

Can you tell me the precise URLs where it talks about the "Linux" system?

GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir]

[Glenn Morris]

Richard Stallman wrote:

> Can you tell me the precise URLs where it talks about the "Linux" system?

I was talking about the source tar ball for the latest bzr release.

http://launchpad.net/bzr/2.0/2.0.2/+download/bzr-2.0.2.tar.gz

Simply download, extract, and `grep -r Linux'.

A selection of matches:

INSTALL:

    When installing bzr you need the ability to build C extensions.
    Some Linux distributions package the necessary headers separately
    from the main Python package.

NEWS:

   * On Linux bzr additionally looks for plugins in arch-independent
     site directory. (Toshio Kuratomi)

doc/en/user-guide/installing_bazaar.txt:

    Linux
    -----

    Bazaar packages are available for most popular Linux distributions
    including Ubuntu/Debian, Red Hat and Gentoo.
    See http://bazaar-vcs.org/Download for the latest instructions.

    Other operating systems
    -----------------------

    Beyond Linux and Windows, Bazaar packages are available for a large
    range of other operating systems...

Re: GNU bzr [was Re: support for bzr shelve/unshelve in vc-dir]

[Richard Stallman]

Thanks for that info about the problems in BZR.

It will be another couple of weeks, probably, before I can bring it up
with them, but I will.

Re: GNU bzr

[Karl Fogel]

Richard Stallman <rms@gnu.org> writes:
> Thanks for that info about the problems in BZR.
>
> It will be another couple of weeks, probably, before I can bring it up
> with them, but I will.

I will bring it up with them today.

-Karl

Re: support for bzr shelve/unshelve in vc-dir

[Martin Pool]

On Fri, 04 Dec 2009 18:52:04 -0500, Glenn Morris wrote:

> Óscar Fuentes wrote:
> 
>> Contributing to Bazaar is difficult, they know it, and the developers
>> are trying to alleviate the process. But in the end, Bazaar is a
>> Canonical product and its development is guided by Canonical's business
>> strategy.

It's guided by Canonical, since they fund a lot of development, but also 
by the patches and proposals that people put up, including non-Canonical 
people and employees in their personal or discretionary time.  Other GNU 
projects have been like this.  

We had got into a pattern of being two conservative and we are indeed 
trying to make it easier.  If you think it's too tough to get a patch in, 
please tell me or tell Karl.
 
> It's also a GNU project. People ought to be able to feel confident about
> contributing to GNU projects. But when I had a quick look at the
> conditions for becoming one:
> 
> http://www.gnu.org/help/evaluation.html
> 
> I couldn't immediately see anything that would alleviate your worries.
> But, I'm not sure exactly what your worries are.

> While reading the conditions on that page, a first glance at the bzr
> 2.0.2 source shows: it is distributed under GPLv2+ rather than v3+,
> http://www.gnu.org/software/bzr does not exist, it does not have texinfo
> documentation, 

We talked about texinfo documentation at the time of accession to GNU.  I 
understand the value in having every GNU program consistent but texinfo 
is not very technically easy given our platform and the technical 
environment of 2009, and in my opinion not a good use of time.  However, 
if someone has an idea by which we can for example produce texinfo as an 
output, we will look at it.

We also don't use automake because it is not a good match for Python, and 
we don't use GUILE.  The document mixes technical recommendations with 
more long-term issues.

> it contains numerous references to the "Linux" operating
> system, 

Apparently Richard will be in touch about this.

> and there doesn't seem to be any reference in the --version
> output or man-page to it being a GNU project.

There are references in the documentation and on the web site, but 
possibly not enough.  I thought I had fixed --version already, but it 
will be fixed now.

These are just bugs.  Reports or patches are always welcome.

-- 
/home/mbp/.signature

Re: support for bzr shelve/unshelve in vc-dir

[Stefan Monnier]

> We talked about texinfo documentation at the time of accession to GNU.
> I understand the value in having every GNU program consistent but
> texinfo is not very technically easy given our platform and the
> technical environment of 2009, and in my opinion not a good use
> of time.

I have no idea what you're referring to.  We all know that Texinfo is
not as sexy as HTML and has its share of shortcomings, but it does its
job fairly well and has several features still mostly unmatched by any
other format (especially when accessed via an Info viewer such as the
one in Emacs).

I think the question shouldn't be "should we do provide Texinfo", but
"how are we going to do it".

> However, if someone has an idea by which we can for example produce
> texinfo as an output, we will look at it.

Not knowing exactly how you generate your documentation, it's hard for
me to help, but at least if you can generate docbook output (which you
supposedly can from ReST), you can pass it on to docbook2x to get
Texinfo output.  Or maybe Pandoc can do it better straight from ReST
to Texinfo.


        Stefan

Re: support for bzr shelve/unshelve in vc-dir

[Martin Pool]

On Wed, 09 Dec 2009 22:46:46 -0500, Stefan Monnier wrote:

>> We talked about texinfo documentation at the time of accession to GNU.
>> I understand the value in having every GNU program consistent but
>> texinfo is not very technically easy given our platform and the
>> technical environment of 2009, and in my opinion not a good use of
>> time.
> 
> I have no idea what you're referring to.  We all know that Texinfo is
> not as sexy as HTML and has its share of shortcomings, but it does its
> job fairly well and has several features still mostly unmatched by any
> other format (especially when accessed via an Info viewer such as the
> one in Emacs).

We've talked about this before, including in the bazaar list thread 
"Printable Documentation" in January this year, and in <https://
bugs.edge.launchpad.net/bzr/+bug/219334> (filed by Stefan.)  Let's 
discuss the practicalities in that bug not on the emacs list.

> I think the question shouldn't be "should we do provide Texinfo", but
> "how are we going to do it".

I agree we should, it is just a question of someone getting around to 
doing the research and making a patch.  Regardless of GNU-ness, there are 
people who find it convenient to read their documentation inside Info and 
we'd like to help them.

-- 
Martin

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Martin Pool <mbp@sourcefrog.net> writes:

  > On Fri, 04 Dec 2009 18:52:04 -0500, Glenn Morris wrote:
  > 
  > > Óscar Fuentes wrote:
  > > 
  > >> Contributing to Bazaar is difficult, they know it, and the developers
  > >> are trying to alleviate the process. But in the end, Bazaar is a
  > >> Canonical product and its development is guided by Canonical's business
  > >> strategy.
  > 
  > It's guided by Canonical, since they fund a lot of development, but also 
  > by the patches and proposals that people put up, including non-Canonical 
  > people and employees in their personal or discretionary time.  Other GNU 
  > projects have been like this.  
  > 
  > We had got into a pattern of being two conservative and we are indeed 
  > trying to make it easier.  If you think it's too tough to get a patch in, 
  > please tell me or tell Karl.

This discussion started in part because of the perceived difficulty of
getting a patch integrated to implement "bzr unshelve --keep"
(https://bugs.launchpad.net/bzr/+bug/492091)
bzr shelves are not very usable without this option, you can't go back
and forth between shelved versions.
The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set 
delete_shelf to False when "--keep" is passed.  So about 3 lines total.

Would such a patch need copyright assignment?
Even if it does, given the above description, a bzr developer can
reproduce the change needed in a few seconds... 
Can you please help get this solved?

Re: support for bzr shelve/unshelve in vc-dir

[Martin Pool]

2009/12/11 Dan Nicolaescu <dann@ics.uci.edu>:
> This discussion started in part because of the perceived difficulty of
> getting a patch integrated to implement "bzr unshelve --keep"
> (https://bugs.launchpad.net/bzr/+bug/492091)

I would be the first to agree that we have made it too hard to get
changes in in the past, and that while we are doing better now we can
still do more.  However, I can't find any history with this particular
request, just a recently-filed bug?

> bzr shelves are not very usable without this option, you can't go back
> and forth between shelved versions.
> The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set
> delete_shelf to False when "--keep" is passed.  So about 3 lines total.
>
> Would such a patch need copyright assignment?
> Even if it does, given the above description, a bzr developer can
> reproduce the change needed in a few seconds...
> Can you please help get this solved?

Yes, it would need copyright assignment.  We do this on every patch
because our legal opinion said that there is no globally-recognized
concept of "too small to copyright", and because we want to have clear
copyright.  Many developers, both at Canonical and otherwise, have
given feedback that they think the FSF approach of saying "about a
paragraph" (or whatever it precisely is) is a reasonable commonsense
tradeoff..

I'll have a look at doing this.  Thanks for looking into it.

-- 
Martin <http://launchpad.net/~mbp/>

Re: support for bzr shelve/unshelve in vc-dir

[Martin Pool]

2009/12/11 Dan Nicolaescu <dann@ics.uci.edu>:
> This discussion started in part because of the perceived difficulty of
> getting a patch integrated to implement "bzr unshelve --keep"
> (https://bugs.launchpad.net/bzr/+bug/492091)
> bzr shelves are not very usable without this option, you can't go back
> and forth between shelved versions.
> The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set
> delete_shelf to False when "--keep" is passed.  So about 3 lines total.
>
> Would such a patch need copyright assignment?
> Even if it does, given the above description, a bzr developer can
> reproduce the change needed in a few seconds...
> Can you please help get this solved?

It's now up for review at
<https://code.edge.launchpad.net/~mbp/bzr/492091-unshelve-keep/+merge/16001>.
 (You can review it if you have or make a Launchpad account.)  I
expect it will be in our December 2.1b4.

-- 
Martin <http://launchpad.net/~mbp/>

Re: GNU bzr

[Karl Fogel]

Karl Fogel <karl.fogel@canonical.com> writes:
> Richard Stallman <rms@gnu.org> writes:
>> Thanks for that info about the problems in BZR.
>>
>> It will be another couple of weeks, probably, before I can bring it up
>> with them, but I will.
>
> I will bring it up with them today.

By the way, I did ask, and it appears there wasn't any conscious
decision not to use "GNU/Linux".  It's just that there hasn't been much
centralized editorial control over the docs, so they get written by
whoever writes them.  I take that to mean that patches would be welcome.

-Karl

Re: support for bzr shelve/unshelve in vc-dir

[Dan Nicolaescu]

Martin Pool <mbp@canonical.com> writes:

  > 2009/12/11 Dan Nicolaescu <dann@ics.uci.edu>:
  > > This discussion started in part because of the perceived difficulty of
  > > getting a patch integrated to implement "bzr unshelve --keep"
  > > (https://bugs.launchpad.net/bzr/+bug/492091)
  > 
  > I would be the first to agree that we have made it too hard to get
  > changes in in the past, and that while we are doing better now we can
  > still do more.  However, I can't find any history with this particular
  > request, just a recently-filed bug?

I don't think that's the whole history here.

  > > bzr shelves are not very usable without this option, you can't go back
  > > and forth between shelved versions.
  > > The patch would change bzrlib/shelf_ui.py:Unshelver.from_args to set
  > > delete_shelf to False when "--keep" is passed.  So about 3 lines total.
  > >
  > > Would such a patch need copyright assignment?
  > > Even if it does, given the above description, a bzr developer can
  > > reproduce the change needed in a few seconds...
  > > Can you please help get this solved?
  > 
  > Yes, it would need copyright assignment.  We do this on every patch
  > because our legal opinion said that there is no globally-recognized
  > concept of "too small to copyright", and because we want to have clear
  > copyright.  Many developers, both at Canonical and otherwise, have
  > given feedback that they think the FSF approach of saying "about a
  > paragraph" (or whatever it precisely is) is a reasonable commonsense
  > tradeoff..

FYI: the FSF policy is to require a copyright assignment from someone
that submits a number of small patches, so it's not possible to work
around the copyright requirement by splitting a larger change into many
smaller ones.

It looks like bzr unshelve --keep will make it into the next version,
thanks for taking care of it!

Re: support for bzr shelve/unshelve in vc-dir

[Martin Pool]

2009/12/19 Dan Nicolaescu <dann@ics.uci.edu>:
> FYI: the FSF policy is to require a copyright assignment from someone
> that submits a number of small patches, so it's not possible to work
> around the copyright requirement by splitting a larger change into many
> smaller ones.

OK, noted.

> It looks like bzr unshelve --keep will make it into the next version,
> thanks for taking care of it!

In fact it's in bzr 2.1b4
<https://edge.launchpad.net/bzr/+milestone/2.1.0b4> released last
week.  2.1 will have its final release in February next year but it's
quite ok to use now.

If you think anything else is stalling or needs help, don't hesitate
to ask.  I know there is one more request there about just showing the
diff (not applying it) for which someone is being mentored iirc.

-- 
Martin