Re: [SOLVED for GNU]

[Uwe Brauer]

>> "Stephen" == Stephen J Turnbull <address@hidden> writes:

   > Uwe Brauer writes:

   >> So the issue are there any plans to port a recent GNU vc pkg to
   >> Xemacs?

   > Of course.  I think the last major sync was done in 2005 or so by
   > Ville Skyttä.  The problem is that there are few workers to do it,
   > and most of us seem to give other plans higher priority.


For example, in the GNU version,  vc-annotate is separated from the rest
of vc and has appropriate keybindings.

   > Note that Stefan Monnier thinks that GNU's vc.el needs a thorough
   > overhaul.

   >> >> "Uwe" == Uwe Brauer <address@hidden> writes:

   >> Thien-Thi Nguyen solved my problem with the following hack

   > I don't see anything hacky about using rlog.  It is the obvious way to
   > get the information.

That was Thien's wording not mine, I presume he thinks he did not use
the vc-annotate engine properly. 

   > Your requirements are hacky, in the sense that the previous revision
   > computed here is typically not the parent of the first revision on a
   > branch.  ("Typically" for all users.  I'm not saying this won't work
   > fine for you, but you should be aware of the gotcha.)  This
   > implementation assumes that once you branch, you close the old branch
   > to further development:

   > trunk  1.1 -- 1.2 -- 1.3 -- 1.4
   >                                \
   > branch 1                        2.1 -- 2.2
   >                                           \
   > branch 2                                   3.1 -- 3.2 -- ...

   > But it would fail to pick out parents if development could continue:

   > trunk  1.1 -- 1.2 -- 1.3 -- 1.4 -- 1.5 -- ...
   >                                \
   > branch 1                        2.1 -- 2.2 -- 2.3 -- ...
   >                                           \
   > branch 2                                   3.1 -- 3.2 -- ...


That is right, once a branch is closed I never go back, I use this
approach for writing publications not for hacking.

   >> (defun vc-minor-part (rev)             ;part of GNU vc
   >> "Return the minor revision number of a revision number REV."
   >> (string-match "[0-9]+\\'" rev)
   >> (substring rev (match-beginning 0) (match-end 0)))
   >> 
   >> (defun vc-trunk-p (rev); part of GNU vc
   >> "Return t if REV is a revision on the trunk."
   >> (not (eq nil (string-match "\\`[0-9]+\\.[0-9]+\\'" rev))))

   > This looks incorrect, if 1.y is your trunk, and x.y for x > 1 are
   > branches.  In that case you should change the regexp to
   > "\\`1\\.[0-9]+\\'".

Well that is not part of the hack but part of GNU Emacs vc.el.
Just in case I put Thien and Emacs-devel in the CC, in case your comment
is relevant for the general case.

   >> (defalias 'vc-rcs-minor-part 'vc-minor-part);23-24 compatibility 
   >> (defalias 'vc-rcs-trunk-p 'vc-trunk-p);23-24 compatibility 
   >> 
   >> (defun vc-rcs-previous-revision (file rev)
   >> "Return the revision number immediately preceding REV for FILE,
   >> or nil if there is no previous revision.  This default
   >> implementation works for MAJOR.MINOR-style revision numbers as
   >> used by RCS and CVS."

   > This is false for CVS.[1]  x.y (almost always 1.y) is a trunk version,
   > branch versions have an even number of components greater than 2.  RCS
   > doesn't encourage such a convention as far as I can tell.

Also CC to Emacs devel.

   >> His solution works with GNU emacs 23 and 24 but, however it does
   >> not work with xemacs

   > There's nothing in the implementation you posted that wouldn't work in
   > XEmacs AFAICS.  I suspect that XEmacs vc just doesn't find the new
   > function.  Try naming the function "vc-rcs-previous-version" instead
   > and see if XEmacs calls it properly.

That is odd, I tried it several times and got an error about number of
arguments, however now it *works*. I keep and eye on that.

Thanks all of you for your help, but I presume this function will not be
included in any official vc version?


Uwe

smime.p7s
Description: S/MIME cryptographic signature