Sometimes when you work on a project, several people make similar
+changes in parallel. When these changes occur in an existing file that
+is known to both sides, monotone can merge the edits when the two
+revisions meet (possibly after getting help to resolve content
+conflicts). Other kinds of changes cannot be merged so readily,
+especially ones that involve files in your workspace that are not
+tracked by monotone.
+
+
Workspace collisions can happen for many reasons; some examples include:
+
+
You have a file in your workspace that is unknown to monotone (you
+have not added it). Someone else has added and
+commited a different file with the same name. If you try to
+update your workspace to their revision, the added file in the
+incoming revision will collide with your file over use of the name.
+
There is a directory which contains both versioned and unversioned files
+(perhaps versioned sources, and unversioned object files built from the
+sources). Someone else commits a revision that
+drops the versioned files and the containing
+directory. If you try to update to this revision, your
+directory will still contain the untracked files, and therefore cannot
+be deleted.
+
You have an unversioned file in your workspace, and you're trying to
+update to a revision that adds a directory with the
+same name.
+
+
+
These examples describe collisions on update; the same kinds
+of things can happen with other commands that can bring changes into
+your workspace, such as checkout or pluck too.
+
+
Monotone is careful to avoid hitting such collisions. Before changing
+the workspace, it will try and detect the possibility of collisions, and
+the command will fail, warning you about the names that collide. The
+file content in the database is safe and can be recovered at any time,
+so monotone is conservative and will refuse to destroy the information
+in your workspace contents.
+
+
However, monotone cannot detect all kinds of failures and collisions in
+your workspace. For example:
+
+
On some systems with case-insensitive and/or internationalised
+filesystems, names that look distinct to monotone may in fact be
+considered the same by the underlying platform.
+
If some other program is creating files in the workspace at the same
+time as monotone, the colliding file might be created after the
+collision check at the start.
+
Other kinds of unpredictable system errors, like permissions problems or
+disk full conditions, might cause failures when monotone is rearranging
+the workspace content.
+
+
+
These are all hopefully very rare occurrences. If such a filesystem
+error does cause a failure part-way during a workspace
+alteration, monotone will stop immediately rather than risk potentially
+doing further damage, and your workspace may be left in an incomplete
+state. If this happens, you will need to resolve the issue and clean up
+the workspace manually. If you need to do so, understanding how
+monotone manipulates the workspace is helpful.
+
+
When monotone applies renaming changes to the workspace, each file is
+first detached from the workspace under its old name, then
+attached under the new name. This is done by moving it to the
+_MTN/detached directory. Newly added files are created here
+before being moved into place, too. While inside _MTN/detached,
+the file or directory is named as a simple integer (these numbers come
+from monotone's internal identification of the node). If the detached
+node is a directory, the directory is moved with all of its contents
+(including unversioned files); this can help identify which directory
+has been detached.
+
+
If a previous workspace alteration failed part-way, the
+_MTN/detached directory will still exist, and monotone will
+refuse to attempt another alteration while the workspace is in this
+inconsistent state. This also acts as a lock against multiple monotone
+processes performing workspace alterations (but not other programs).
+
+
The best way to avoid a messy recovery from such a failure is simply to
+ensure that you always commit before trying to
+update (or pluck, etc) other changes from the
+database into your workspace. This ensures that your current workspace
+contents are safely stored, and can be retrieved later (such as with
+revert).
+
+
+
============================================================
--- INSTALL 57518aa598e6c62cb9c2f74fd102091b489bfcc4
+++ INSTALL e0f783d8e7b4ba600407c7d1f22493408195a506
@@ -21,7 +21,6 @@ 1. prerequisites:
apt-get install libboost-date-time-dev
apt-get install libboost-filesystem-dev
apt-get install libboost-regex-dev
- apt-get install libboost-serialization-dev
apt-get install libboost-test-dev
apt-get install libboost-dev
apt-get install g++
============================================================
--- NEWS baff89704e514e465db0099404e03457e7127f4f
+++ NEWS 08261921b0db1ef853bd36576c47bcb3657f1ddb
@@ -1,3 +1,86 @@
+Tue Feb 27 18:46:58 UTC 2007
+
+ 0.33 release.
+
+ The internal data format has changed with this release;
+ migration is straight-forward. To upgrade your databases,
+ you must run:
+ $ mtn -d mydb.mtn db migrate
+ All of these operations are completely lossless, and 0.33
+ remains compatible with earlier versions with regards to
+ netsync.
+
+ Changes
+
+ - "mtn ls unknown" no longer recurses into unknown directories.
+
+ - update will fail rather than clobbering unversioned files
+ that exist in the workspace.
+
+ - update will detect directories with unversioned files before
+ attempting to drop them and will refuse to run rather than
+ corrupting the workspace. such unversioned files must be
+ removed manually.
+
+ - the character set and line separator conversion hooks
+ (get_system_linesep, get_charset_conv and get_linesep_conv)
+ have been removed. Similar functionality (probably based on
+ file type attributes) is planned and will be added in a future
+ release.
+
+ - update will switch to the branch of a given revision if it
+ differs from the current workspace branch.
+
+ - add will now accept combinations of --unknown, --recursive and
+ --no-respect-ignore.
+
+ - import now imports unknown directory trees properly.
+
+ - use SQLite 3.3.12.
+
+ - schema migrator rebuilt and will now properly detect and report
+ if the database used is created by a newer monotone than the one
+ currently used.
+
+ - removed the man page mtn.1, as it hadn't been updated for a long
+ time.
+
+ New features
+
+ - "mtn merge_into_workspace" (still to be documented)
+
+ - "mtn log" will now print an ASCII revision graph alongside the
+ usual log text.
+
+ Speed improvements
+
+ - "mtn annotate file" should run even faster now. it exploits
+ the fact that we store deltas of rosters. by peeking at
+ these deltas, it can avoid reconstruction of whole rosters
+ in many cases.
+
+ Other
+
+ - contrib/monotone-mirror.sh and
+ contrib/monotone-mirror-postaction-update.sh, two scripts
+ to mirror and update directories automatically.
+
+ - contrib/monotone-run-script-post-netsync.lua, to automatically
+ update a directory as soon as new revisions or certs arrive for
+ a given branch.
+
+ - contrib/monotone.bash_completion had some improvemens.
+
+ - contrib/monotone.el had some improvements.
+
+ Internal
+
+ - Internally, the concept of "projects" has been introduced. It
+ currently doesn't mean anything, but will be used later, with
+ policy branches and similar.
+
+
+
Wed Dec 27 09:57:48 UTC 2006
0.32 release.
============================================================
--- UPGRADE d937bff0f8a61653efd71e8322918283efa15660
+++ UPGRADE 128b39c8de9f33b4763cc69e06baba9ee10b06a2
@@ -1,4 +1,4 @@
-upgrading monotone to 0.32
+upgrading monotone to 0.33
==========================
How to read this file:
@@ -16,6 +16,10 @@ If you are upgrading from:
will be described there, not here.
If you are upgrading from:
+ - 0.32 or earlier: The database format has changed. You must run
+ (after remembering to take a backup copy):
+ $ mtn -d mydb.mtn db migrate
+ on each of your databases.
- 0.31 or earlier: The database format has changed. You must run
(after remembering to take a backup copy):
$ mtn -d mydb.mtn db migrate
============================================================
--- docs/Additional-Lua-Functions.html d1315ca4877bee82c52f4e8ea1ae6b210bc8a0f7
+++ docs/Additional-Lua-Functions.html a20e1a6abc7f30e909076b1f295832bb768f0ab2
@@ -32,60 +32,60 @@ Up: 6.2 Additional Lua Functions
-
This function receives a string containing the name of an external
program and returns 0 if it exists on path and is executable, -1
otherwise.
As an example, existonpath("xxdiff") returns 0 if the
program xxdiff is available.
-On windows, this function automatically appends “.exe” to the
+On Windows, this function automatically appends “.exe” to the
program name. In the previous example, existonpath would search
for “xxdiff.exe”.
-
guess_binary(filespec)
+
guess_binary(filespec)
Returns true if the file appears to be binary, i.e. contains one or
more of the following characters:
0x00 thru 0x06
0x0E thru 0x1a
0x1c thru 0x1f
-
include(scriptfile)
+
include(scriptfile)
This function tries to load and execute the script contained into
scriptfile. It returns true for success and false if there is an
error.
-
includedir(scriptpath)
+
includedir(scriptpath)
This function loads and executes in alphabetical order all the scripts
contained into the directory scriptpath.
If one of the scripts has an error, the functions doesn't process the
remaining scripts and immediately returns false.
-
includedirpattern(scriptpath, pattern)
+
includedirpattern(scriptpath, pattern)
This function loads and executes in alphabetical order all the scripts
contained into the directory scriptpath that match the given pattern.
If one of the scripts has an error, the functions doesn't process the
remaining scripts and immediately returns false.
-
is_executable(filespec)
+
is_executable(filespec)
This function returns true if the file is executable, false
-otherwise. On windows this function returns always false.
+otherwise. On Windows this function returns always false.
-
kill(pid [, signal])
-This function calls the kill() C library function on posix systems and
+
kill(pid [, signal])
+This function calls the kill() C library function on POSIX systems and
TerminateProcess on Win32 (in that case pid is the process
handle). If the optional signal parameter is missing, SIGTERM
will be used.
-Returns 0 on succes, -1 on error.
+Returns 0 on success, -1 on error.
-
make_executable(filespec)
-This function marks the named file as executable. On windows has no
+
make_executable(filespec)
+This function marks the named file as executable. On Windows has no
effect.
-
mkstemp(template)
+
mkstemp(template)
Like its C library counterpart, mkstemp creates a unique name and
returns a file descriptor for the newly created file.
The value of template should be a pointer to a character buffer loaded
@@ -107,14 +107,14 @@ For the definition of temp_file()<
file in the standard TMP/TEMP directories.
For the definition of temp_file(), see Default hooks.
-
sleep(seconds)
+
sleep(seconds)
Makes the calling process sleep for the specified number of seconds.
-
spawn(executable [, args ...])
+
spawn(executable [, args ...])
Starts the named executable with the given arguments. Returns the
-process pid on Posix systems, the process handle on Win32 or -1 if
+process PID on POSIX systems, the process handle on Win32 or -1 if
there was an error.
-Calls fork/execvp on Posix, CreateProcess on Win32.
+Calls fork/execvp on POSIX, CreateProcess on Win32.
Important notice:
To spawn a process and wait for its completion, use the execute()
@@ -122,13 +122,13 @@ in a standardized way.
option. execute() builds on spawn() and wait()
in a standardized way.
-
wait(pid)
-Wait until the process with given pid (process handle on Win32) exits.
+
wait(pid)
+Wait until the process with given PID (process handle on Win32) exits.
Returns two values: a result value and the exit code of the waited-for
process.
The exit code is meaningful only if the result value is 0.
-
parse_basic_io(data)
+
parse_basic_io(data)
Parse the string data, which should be in basic_io format. It returns nil
if it can't parse the string; otherwise it returns a table. This will be a list
of all statements, with each entry being a table having a "name" element that is
============================================================
--- docs/Advanced-Uses.html 5905ee7baf20c59c6fd828c1004add6579745697
+++ docs/Advanced-Uses.html 8321cf86cedd263616c8d270eec3749a75d7502a
@@ -45,10 +45,11 @@ familiarize yourself with its operation.
Restrictions: Limit workspace changes to specified files.
-Prints the descendents of one or more revisions.
+Prints the descendants of one or more revisions.
Sample output:
@@ -210,13 +210,13 @@ Prints the descendents of one or more re
Output format:
-Zero or more lines, each giving the ID of one descendent of the given
+Zero or more lines, each giving the ID of one descendant of the given
revisions. Each line consists of a revision ID, in hexadecimal,
followed by a newline. The lines are printed in alphabetically sorted
order.
The output does not include rev1, rev2, etc., except that if
-rev2 is itself a descendent of rev1, then rev2 will be
+rev2 is itself a descendant of rev1, then rev2 will be
included in the output.
Error conditions:
@@ -315,7 +315,7 @@ are no arguments, prints nothing.
Output format:
-Zero or more lines, each giving the ID of one descendent of the given
+Zero or more lines, each giving the ID of one descendant of the given
revisions. Each line consists of a revision ID, in hexadecimal,
followed by a newline. The lines are printed in alphabetically sorted
order.
@@ -407,7 +407,7 @@ children. This is similar, but not iden
Prints the leaves of the revision graph, i.e. all revision that have no
children. This is similar, but not identical to the functionality of
heads, which prints every revision in a branch, that has no
-descendents in that branch. If every revision in the database was in
+descendants in that branch. If every revision in the database was in
the same branch, then they would be identical. Generally, every leaf is
the head of some branch, but not every branch head is a leaf.
@@ -437,7 +437,7 @@ Prints all branch certs present in the r
Purpose:
Prints all branch certs present in the revision graph, that are not
-excluded by the lua hook ignore_branch.
+excluded by the Lua hook ignore_branch.
Sample output:
@@ -467,7 +467,7 @@ tags of the revision graph.
revisions on branches matched by the pattern; otherwise prints all
tags of the revision graph.
-
If a branch name is ignored by means of the lua hook
+
If a branch name is ignored by means of the Lua hook
ignore_branch, it is neither printed, nor can it be matched by
a pattern.
@@ -517,7 +517,7 @@ blank line. Values will be escaped, '\'
Stanzas are printed in arbitrary order.
Error conditions:
-A run-time exception occures if an illegal branch pattern is
+A run-time exception occurs if an illegal branch pattern is
specified.
@@ -688,7 +688,7 @@ are not valid, detailed below.
' ' unchanged
' P' patched (contents changed)
' U' unknown (exists on the filesystem but not tracked)
- ' I' ignored (exists on the filesystem but excluded by lua hook)
+ ' I' ignored (exists on the filesystem but excluded by Lua hook)
' M' missing (exists in the manifest but not on the filesystem)
' A ' added (invalid, add should have associated patch)
@@ -886,7 +886,7 @@ provided as 'l' <string> [<stri
The input is a series of commands. The command name plus arguments are
provided as 'l' <string> [<string> ...] 'e', where <string> = <size> colon
-<data> . This may optionally be preceeded by a set of key=value pairs
+<data> . This may optionally be preceded by a set of key=value pairs
(command options) as 'o' <string> <string> [<string> <string> ...] 'e', where
strings come in pairs, key followed by value.
============================================================
--- docs/CVS-Phrasebook.html 38db39f172da9f8f255c813651c991c729aff093
+++ docs/CVS-Phrasebook.html 74d9762c96bb7e130c3b086205599ecbc668c36a
@@ -120,7 +120,7 @@ omit the mer
communication step with monotone. The extra command, merge,
ensures that the branch your are working on has a unique head. You can
omit the merge step if you only want update to
-examine descendents of your base revision, and ignore other heads on
+examine descendants of your base revision, and ignore other heads on
your branch.
Tagging Revisions
============================================================
--- docs/Committing-Work.html e0c6ae7079f37eb8970bec9f0b176abbdf6edc16
+++ docs/Committing-Work.html 0ac9fe948d6d6765c0b282198521f0d63122ae45
@@ -109,8 +109,8 @@ the revision Jim just committed. A head
The output of this command tells us that there is only one current
“head” revision in the branch jp.co.juicebot.jb7, and it is
the revision Jim just committed. A head revision is one without any
-descendents. Since Jim has not committed any changes to this revision
-yet, it has no descendents.
+descendants. Since Jim has not committed any changes to this revision
+yet, it has no descendants.