11:23 a.m.
Hello
I use this function a lot, but I also checkin jumping branches
1.1 1.2 1.3 1.4
2.1 2.2
But then (vc-annotate-revision-previous-to-line) can go back from 2.2 to
2.1 but not to 1.4.
Anybody knows about a hack to achieve jumping from 2.1 to 1.4.
thanks
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:44 p.m.
New subject: [SOLVED for GNU] (was: (vc-annotate-revision-previous-to-line) rcs, cannot go back)
> "Uwe" == Uwe Brauer <oub(a)mat.ucm.es> writes:
Hello
I use this function a lot, but I also checkin jumping branches
1.1 1.2 1.3 1.4
2.1 2.2
But then (vc-annotate-revision-previous-to-line) can go back from 2.2
to
2.1 but not to 1.4.
Thien-Thi Nguyen solved my problem with the following hack
(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))))
(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."
(let ((branch (vc-branch-part rev))
(minor-num (string-to-number (vc-rcs-minor-part rev))))
(when branch
(if (> minor-num 1)
;; revision does probably not start a branch or release
(concat branch "." (number-to-string (1- minor-num)))
(if (vc-rcs-trunk-p rev)
;; we are at the beginning of the trunk --
(let* ((trunk-num (string-to-number branch))
(prev (1- trunk-num))
(out (shell-command-to-string
(format "rlog -r%d. '%s'" prev file))))
(if (string-match "^revision \\(.+\\)$" out)
;; return the highest revision on the previous trunk
(match-string 1 out)
;; don't know anything to return here
nil))
;; we are at the beginning of a branch --
;; return revision of starting point
(vc-branch-part branch))))))
The basic idea is to use rlog in an appropriate way (that is why
Thien-Thi Nguyen called it a hack). His solution works with GNU emacs 23
and 24 but, however it does not work with xemacs[1], in fact the vc pkg
of both emacsen are quite different, I would even say the Xemacs version
is older (and inferior).
So the issue are there any plans to port a recent GNU vc pkg to Xemacs?
Or does anybody have an idea, based on the solution above, how to
implement this feature in Xemacs?
thanks
Uwe Brauer
Footnotes:
[1] this is not entirely true. I can call xemacs version of
vc-annotate, then I load GNU emacs vc.el, vc-dispatcher.el,
vc-annotate.el and vc-rcs-previous-revision (which contains the new
hack), then I can decrement the RCS version as I like, however then
I cannot checkin or checkout, so I have to load xemacs vc.el
again. Oh....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:25 a.m.
New subject: [SOLVED for GNU] (was: (vc-annotate-revision-previous-to-line) rcs, cannot go back)
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.
Note that Stefan Monnier thinks that GNU's vc.el needs a thorough
overhaul.
>> "Uwe" == Uwe Brauer <oub(a)mat.ucm.es> 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.
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 -- ...
(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]+\\'".
(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.
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.
Footnotes:
[1] I am so glad I work on XEmacs where we at least occasionally care
about getting this kind of thing right....
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:29 a.m.
New subject: [SOLVED for GNU]
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> 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 <oub(a)mat.ucm.es>
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
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:17 a.m.
New subject: [SOLVED for GNU]
Removing Thi from the CC list; he'll see it on emacs-devel.
Uwe Brauer writes:
> 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.
No, it's not.
I'm not sure what the general case looks like for RCS (or even if
there is one, any more -- I'm sure there are a lot of people who still
use RCS for one reason or another but I bet they have a million
different conventions for version numbering).
> 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.
Good. It doesn't really surprise me that it took a few tries.
Because of the way that vc.el manages its various engines, you might
have to switch to another one then back to RCS, or kill a buffer and
reread the file, or ..., to get the new function insinuated.
Let us know if it decides to fail again.
Thanks all of you for your help, but I presume this function will not
be
included in any official vc version?
I don't see why not. Although the difference between "parent" and
"head of previous branch" is important, since RCS doesn't know about
parents as far as I can see, "head of previous branch" seems like a
good approximation.
Emacs may have a different opinion, of course.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
5:47 p.m.
New subject: [SOLVED for GNU]
> "Stephen" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
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 -- ...
Just for the protocol, I have also tried (maybe misunderstanding
something fundamental), branching along the 1.1 trunk in a different way
Trunk 1.1--1.2
\
branch 1: 1.2.1.1--1.2.1.2--1.2.1.3
However then I wanted to use the content of 1.2.1.3 to continue in the
trunk as 1.3, the this did not work. On the other hand, as you indicate
in your diagram this is possible with trunk 1, branch 2, branch 3 etc.
Uwe Brauer
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:25 p.m.
New subject: [SOLVED for GNU]
Uwe Brauer writes:
Just for the protocol, I have also tried (maybe misunderstanding
something fundamental), branching along the 1.1 trunk in a different way
Trunk 1.1--1.2
\
branch 1: 1.2.1.1--1.2.1.2--1.2.1.3
However then I wanted to use the content of 1.2.1.3 to continue in the
trunk as 1.3, the this did not work.
Yeah, RCS seems to be pretty picky about the version numbers allowed
with using rcsmerge or co -j to combine versions. I guess to get that
effect you would need to copy 1.2.1.3 to a temp file, co -r 1.2, then
ci.
I think it would be easier to use git.... But only you can know for
sure.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4226
days inactive
4235
days old
6 comments
2 participants
participants (2)
-
Stephen J. Turnbull -
Uwe Brauer