~ubuntu-branches/ubuntu/trusty/tla/trusty

« back to all changes in this revision

Viewing changes to src/docs-tla/texi/introducing-replay.texi

  • Committer: Bazaar Package Importer
  • Author(s): Andrew Suffield
  • Date: 2004-05-30 20:13:29 UTC
  • Revision ID: james.westby@ubuntu.com-20040530201329-mgovd2u99mkxi0hf
Tags: upstream-1.2
ImportĀ upstreamĀ versionĀ 1.2

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
@need 3200
 
2
 
 
3
@node Introducing replay -- An Alternative to update
 
4
@chapter Introducing replay -- An Alternative to update
 
5
 
 
6
@code{update} isn't the only way to catch-up with a development path.
 
7
Another option is @code{replay}:
 
8
 
 
9
@example
 
10
@group
 
11
        % cd ~/wd/project-tree
 
12
        % tla replay
 
13
        [....]
 
14
@end group
 
15
@group
 
16
@end group
 
17
@end example
 
18
 
 
19
What does that actually do?
 
20
 
 
21
@need 3200
 
22
 
 
23
@section An update Refresher
 
24
 
 
25
Let's suppose that we check out an old version of @code{hello-world}:
 
26
 
 
27
@example
 
28
@group
 
29
        % cd ~/wd
 
30
        % tla get hello-world--mainline--0.1--patch-1 hw-patch-1
 
31
        [...]
 
32
@end group
 
33
@group
 
34
@end group
 
35
@end example
 
36
 
 
37
It's easy to see that the resulting tree is not up-to-date:
 
38
 
 
39
@example
 
40
@group
 
41
        % cd hw-patch-1
 
42
        % tla missing
 
43
        patch-2
 
44
        patch-3
 
45
@end group
 
46
@group
 
47
@end group
 
48
@end example
 
49
 
 
50
Now, let's suppose that we make some local changes in @code{hw-patch-1} and
 
51
then run @code{update}.   What happens?
 
52
 
 
53
 
 
54
@strong{Local changes are computed against patch-1.}  In other words, 
 
55
a changeset is created that represents the changes from a 
 
56
pristine copy of the @code{patch-1} revision to the current state
 
57
of the project tree (@code{hw-patch-1}).
 
58
 
 
59
 
 
60
@strong{A copy of patch-3 is checked out.}  @code{update} starts with a pristine
 
61
copy of the @code{patch-3} revision.
 
62
 
 
63
 
 
64
@strong{The changeset is applied to the patch-3 tree.}  The changes computed
 
65
in the first step are made to the new tree.
 
66
 
 
67
 
 
68
There's another way, though:
 
69
 
 
70
 
 
71
 
 
72
 
 
73
@need 3200
 
74
 
 
75
@section The replay Command
 
76
 
 
77
We have a local copy of the @code{patch-1}, perhaps with some local
 
78
changes:
 
79
 
 
80
@example
 
81
@group
 
82
        % cd ~/wd/hw-patch-1
 
83
        % tla missing
 
84
        patch-2
 
85
        patch-3
 
86
@end group
 
87
@group
 
88
@end group
 
89
@end example
 
90
 
 
91
Recall that the @code{patch-2} and @code{patch-3} revisions each correspond to a
 
92
specific changeset, stored in the archive (see @strong{How it Works -- commit of a New Revision} in @ref{Checking-in Changes}).
 
93
 
 
94
 
 
95
We could add those changes to your local tree by using @code{get-changeset}
 
96
to retrieve each changeset, and @code{dopatch} to apply it (see
 
97
@strong{get-changeset Retrieves a Changeset from an Archive} in @ref{Exploring Changesets}, and
 
98
@ref{dopatch}).  That's a lot of tedious work, though, so @code{arch}
 
99
provides a more automated way to accomplish that same effect:
 
100
 
 
101
@example
 
102
@group
 
103
        % cd ~/wd/hw-patch-1
 
104
        % tla replay
 
105
        [....]
 
106
        % tla missing
 
107
        [no output]
 
108
@end group
 
109
@group
 
110
@end group
 
111
@end example
 
112
 
 
113
@code{replay} will do just what we've described: get patches
 
114
from the archive and apply them one-by-one.   One word of caution,
 
115
though: if one of those patches generates conflicts, @code{replay} will
 
116
stop there and let you fix the conflicts.  You can then pick up where
 
117
@code{replay} left off by running @code{replay} a second time.
 
118
 
 
119
 
 
120
 
 
121
 
 
122
@need 3200
 
123
 
 
124
@section How it Works -- replay
 
125
 
 
126
If you've followed along with the tutorial so far, the way that @code{replay}
 
127
works should be pretty obvious.  In fact, it's just exactly how we
 
128
described it above.  @code{replay} uses @code{missing} to find out what changes
 
129
your tree is missing, @code{get-changeset} to retrieve those changesets, and
 
130
@code{dopatch} to apply them.  There's a fair amount of "bookkeeping"
 
131
involved in doing that -- and that bookkeeping is what @code{replay}
 
132
automates for you.
 
133
 
 
134
 
 
135
 
 
136
 
 
137
 
 
138
 
 
139