There are two primary modes of operation when checking out sources from Fossil: incremental and full.
An incremental checkout uses an existing checkout and simply updates it to the new revision:
fossil revert
fossil update <revision>
The revert command ensures that changes to any version controlled files are reverted before updating to the new revision. This means that all files under version control will be as checked in.
Any non-versioned files existing in the checkout are left as is. This means that object files from previous builds can be reused for incremental builds.
A full checkout does lot leave any non-versioned files behind from previous builds. There are different methods for ensuring this.
The most gentle method relies on fossil clean
:
fossil revert
fossil clean --verily
fossil update <revision>
This is the fastest since most versioned files can stay in place.
This will completely delete the working directory and check out a fresh copy from the repository:
rmdir <workdir>
fossil open --workdir <workdir> --empty
fossil update <revision>
The Fossil repository is maintained outside the working directory, and it is reused between checkouts.
Clobber everything and clone the repository anew:
rm <repo>
rmdir <workdir>
fossil clone <repourl> <repo>
fossil open --workdir <workdir> --empty
fossil update <revision>
This is the slowest method with the most network traffic.
The JSON API GET /json/timeline/checkin?files=1
is better than RSS because it includes names of changed files, and it requires less clever parsing to extract tags etc.
Doesn't work with --repolist
in version 2.13 and earlier. Fixed in 2.14.
Requires h
capabilities which the nobody
user normally doesn't have.
- Give
h
capabilities tonobody
, or - Log in as
anonymous
, or - Create proper account for buildbot.
See Defense Against Spiders for why the nobody
user should not have Hyperlinks capabilities.
Fossil logins are probably only required for the JSON poller. RSS polling and cloning for checkouts normally don't require auth.
Response codes will indicate when auth is required.
POST to /json/login
with form parameters name=
and password=
. Get back JSON payload:
"payload" : {
"authToken" : "49B18223XXXXXXXXXXXXXXXXXXXXXXXXX8992375B/xxxxxxxxxfb39b/jolesen",
"name" : "jolesen",
"capabilities" : "s",
"loginCookieName" : "fossil-xxxxxxxxxfb39b"
}
The response also contains a corresponding Set-Cookie
header.
In subsequent requests, either pass the cookie $loginCookieName=$authToken
, or pass a query parameter authToken
.
Request the password with GET /json/anonymousPassword
to receive:
"payload" : {
"password" : "0e06d5c8",
"seed" : 1057836951
},
Then proceed to POST /json/login
as above with an additional anonymousSeed=$seed
form parameter.
The treq
package doesn't have a session which keeps track of cookies, and we also can't get the cookies from a response in a portable way.
Solution: Build a loginCookie = { loginCookieName: authToken }
dict after logging in, and pass that with get(cookies=loginCookie)
on every request. We can also persist loginCookie.