1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
<html lang="en">
<head>
<title>ECB - the Emacs Code Browser</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name=description content="ECB - the Emacs Code Browser">
<meta name=generator content="makeinfo 4.2">
<link href="http://www.gnu.org/software/texinfo/" rel=generator-home>
</head>
<body>
<p>
Node:<a name="Checking%20the%20state">Checking the state</a>,
Next:<a rel=next accesskey=n href="Remote-repositories.html#Remote%20repositories">Remote repositories</a>,
Previous:<a rel=previous accesskey=p href="Identifying-backends.html#Identifying%20backends">Identifying backends</a>,
Up:<a rel=up accesskey=u href="Version-control-support.html#Version-control%20support">Version-control support</a>
<hr><br>
<h4>How ECB checks the VC-state of a file</h4>
<p>After ECB has identified the VC-backend of a directory it will display
the VC-state (e.g. up-to-date, edited, needs-mergs etc...) with a
suitable image-icon in the tree-windows of the ECB-file-browser. To
get this state for a certain file ECB uses that check-state-function
stored in the cache for the directory of that file (see <a href="Identifying-backends.html#Identifying%20backends">Identifying backends</a>).
<p>You can add any arbitrary functions as check-state-function to
<code>ecb-vc-supported-backends</code> as long as they get one
filename-argument and return a state-symbol (e.g. <code>up-to-date</code>.
ECB can understand a certain set of state-values which are then
mapped to suitable image-icons which will in turn be displayed in
front of the filename in the file-browser. Because the values a
check-state-function return can differ from that state-values ECB
understands, ECB offers an option to define a appropriate
state-mapping. The name of this option is <code>ecb-vc-state-mapping</code>.
See the documentation of this option to get a list of all state-value
ECB understands.
<p>Per default ECB uses - when running under GNU Emacs - the function
<code>vc-state</code> of the VC-package<a rel=footnote href="#fn-1"><sup>1</sup></a> to check the state for the backends CVS, RCS, SCCS and
Subversion. So the default-value of <code>ecb-vc-state-mapping</code>
contains a mapping between these values <code>ecb-vc-state</code> can return and
that state-values ECB understands.
<p>If ECB should support other VC-backends than CVS, RCS, SCCS and
Subversion (e.g. Clearcase) you should add that new backend to the
VC-package (see the initial comments of vc.el how to do this) then ECB
will automatically support that new backend. Alternatively it may be
sufficient if you write your own check-state-function for this backend and
add the needed mapping to <code>ecb-vc-state-mapping</code> if necessary.
<h5>Getting heuristic state-values or real ones for CVS</h5>
<p>The interface of GNU Emacs' VC-package offers two different ways to
get the VC-state of a file:
<ul>
<li>The real, fresh and expensive approach
VC has a function <code>vc-recompute-state</code> which always performs a
command "cvs status" to get a fresh and real state for a file. As
you can imagine this operation can be very expensive and long lasting
depending on the location of the repository. But the CVS-backend of VC
offers with the option <code>vc-cvs-stay-local</code> a way to tell Emacs to
stay local even for the sake of getting a real state.
<li>The heuristic approach:
The function <code>vc-state</code> always returns a "heuristic" state
which should be used when a fresh and real state is not necessary.
With <code>vc-state</code> the option <code>vc-cvs-stay-local</code> will never
take effect.
</ul>
<p>VC/CVS actually does it this way (regardless if ECB is active or not):
When you visit a file, it always uses just the heuristic to get the
state (comparing file times), regardless of the setting of
<code>vc-cvs-stay-local</code>. This is because the "fresh-but-slow" state
is determined by calling "cvs status" on the file, and this was deemed
unacceptably slow if done at visiting time under any conditions.
<p>The state is updated by calling <code>vc-recompute-state</code> prior to
<code>vc-next-action</code> (C-x v v) which either checks a file in or out.
IF <code>vc-cvs-stay-local</code> is nil, then this does in fact call "cvs
status" to get the "fresh-but-slow-state", but if
<code>vc-cvs-stay-local</code> is t, then it just compares the file times
again.
<p>But under certain conditions (e.g. if called for files not already
visited or for files their VC-state has been changed from outside
Emacs, e.g. by checking in the file via command line) <code>vc-state</code>
does not compute a new heuristic state but returns a cached one
(cached by the VC-package itself not by ECB) which does not reflect
the current VC-state. Example: if you have edited a file within Emacs
and then checked in from outside Emacs <code>vc-state</code> returns a wrong
state until you call <code>revert-buffer</code> for this file. Therefore ECB
offers the check-state-function <code>ecb-vc-state</code> which does the
same as <code>vc-state</code> but it clears the internal caches of the
VC-package for that file before calling <code>vc-state</code>.
<p>The bottom line for you is this: If you use <code>ecb-vc-state</code> in
<code>ecb-vc-supported-backends</code> to get the version control state,
then you get the same policy that VC uses and you get always a
"correct" heuristic state (as correct as possible a heuristic state
can be). There should no harm if you use <code>vc-recompute-state</code> as
a replacement function if you want to get fresh and real state-values,
but then (a) you must make sure to set <code>vc-cvs-stay-local</code> to
nil, and (b) fetching the state over the network under all conditions
was deemed unacceptably slow in VC.
<hr><h4>Footnotes</h4>
<ol type="1">
<li><a name="fn-1"></a>
<p>The VC-package of Emacs
offers a standardised and uniform interface for several backends; per
default CVS, RCS, SCCS and Subversion are supported by the
VC-package.</p>
</ol><hr>
</body></html>
|
