#
#
# rename "tests/t_diff_outside_working_dir.at"
# to "tests/t_diff_outside_workspace.at"
#
# rename "tests/t_log_outside_working_dir.at"
# to "tests/t_log_outside_workspace.at"
#
# patch "ChangeLog"
# from [dc047c34670d6f0a5fa1183eee56574e3ee946db]
# to [f1cc93958169d7455c8c6d1b70cef3c744110ab1]
#
# patch "HACKING"
# from [9192838166bf96f1f7d8369bc1ac8fcc8dc74be7]
# to [dd8654f0de0f726639e8fc988b30e6ac272c173d]
#
# patch "ROADMAP"
# from [53568f4fbd5d01ef09b991793d62f0fd2a0db58f]
# to [745d2ad91a86dc235175a570896ae219fb9853ac]
#
# patch "app_state.cc"
# from [9457a5a86bf5be3837482583ed08164b53e20541]
# to [18045740e735562c70e3a482927003729014844f]
#
# patch "app_state.hh"
# from [2f43fc74c88fdbbfdeeef1c966a2a811ee2e0c20]
# to [7fa51b357c748547e5d71dbc84fb35077c148177]
#
# patch "automate.cc"
# from [0b608759447d6c0c9f4aed5289f60a89decac403]
# to [68d579fc833b4a0ec52a0c8e5b130af7517ab7ed]
#
# patch "commands.cc"
# from [7a8a08ebb4f9834aef113c20c529870cb10c5e6b]
# to [2f64f75b9afb4a86bac84bcc6cacaba86866be2b]
#
# patch "database.cc"
# from [bfb031cff2341ac7363ac7731326c98aacaa819a]
# to [430079748f8733f34aa2f781847a905d85983436]
#
# patch "diff_patch.cc"
# from [622032933fcadaeec86c9fd3c90f157d96b3f6e3]
# to [62b598d468407c93c6b573a1e7eb97bdd52644c8]
#
# patch "diff_patch.hh"
# from [094dfdf8f752939ee4dac54366939df07e20898a]
# to [fb7ab63b1e55fe0278df0c422cd090f555516326]
#
# patch "file_io.hh"
# from [78b32a51c65a8e43b200d72c1dc8f6871bb59267]
# to [2082dc3c8480400f32fcbe1c4d881d7512de2204]
#
# patch "lua.cc"
# from [c8c228b16b396eaf8cbc1b41ca6363593e9abfee]
# to [78722201fdc513bfee248ce6b30b1b1ae593250e]
#
# patch "lua.hh"
# from [71e2943fa623254b4e3e1340e1f8c4b442271a6c]
# to [0d1c63ed6c7b36665ad92780ed88afa1edff3194]
#
# patch "merge.hh"
# from [cd2797de2edf9cc40867385e4a8167be98e7ddfa]
# to [d8869e646a690f203ff3c85764929d89399f16cd]
#
# patch "monotone.1"
# from [abc1b6e19fe0af125d2a12299c52e0eedc25989f]
# to [f7f22f2d6e5bebf0d526d15651869113fe9c6ead]
#
# patch "monotone.cc"
# from [6848daed4195f9d60a08843ac91bdd9e95df2f4f]
# to [92399bda2cd0fba92739636d7b0955c1c43bea23]
#
# patch "monotone.texi"
# from [4c4f7dba85aa2a7d4b5c1d870f5da99046be0ab0]
# to [59eb4911052af4a3a1743caf529acfe14dad092b]
#
# patch "paths.cc"
# from [a88d2a803ce9e069bd8b0b6d5db4d2c2593de689]
# to [227025632497d6849fc4946feeded4d7980f7008]
#
# patch "paths.hh"
# from [f61b1b0f8a6fe9f4b6a55ff1a5513412856cb75c]
# to [727b9cfba7c9d150dfd7144d0d38744beb8dda7f]
#
# patch "platform.hh"
# from [f0d95c6add214117b2aa25646a9f62f750764a53]
# to [0219de39c44ef3898973d9568b5ce26593dbca7c]
#
# patch "roster.cc"
# from [67380c22a3dfef07d49edbc75646a4b0668de5cb]
# to [e1c0e9fe71f80b5bd457801d3cf4eb3240872c22]
#
# patch "std_hooks.lua"
# from [a5e3529e680469a911323f45286466780088f35d]
# to [1740ad529749fadac6c115b8373ca26e9f932ad6]
#
# patch "tests/t_add_vs_commit.at"
# from [795e4288501968701031a986173a6d3d4bfce367]
# to [854fb99182fa82f283d2a26b089e770909461fa5]
#
# patch "tests/t_automate_inventory.at"
# from [390524783f3f55102d9d20a3606cff4b09ed9722]
# to [1a9fcca95a722a81cf5fe49a6dd7025900c4e311]
#
# patch "tests/t_commit_message_file.at"
# from [447a09a7a56815e3298f30a6c84a89882340c029]
# to [ff5ee2bfe41e4807ee909ee5319db3d7eff38173]
#
# patch "tests/t_cvsimport.at"
# from [cdb0a29f99f219dd5c2f4ebb2f3da47003ca10d7]
# to [42e05f340ace04dd4bfdc4e948ab651669f8d2b8]
#
# patch "tests/t_cvsimport_samelog.at"
# from [ccac785c1ac8421e23723f4cdd9e69ce10be7e93]
# to [515ea15748990c4be6f61a9a811266b58fb331e7]
#
# patch "tests/t_database_check.at"
# from [b034de4e58d344e3ac343a04f29bea851aa93717]
# to [332a5aec62e318573ab12e222b0cd31e56951b97]
#
# patch "tests/t_diff_outside_workspace.at"
# from [68e1ab2a3186b905dc91af7814cb0dc10594bb3f]
# to [28c8bf8ea6fc2088a754308386f6ab936506dc77]
#
# patch "tests/t_drop_missing.at"
# from [76df22384469606ea77735754609229018a6f6a5]
# to [b57855a8b89e7f7c8c7cab3ae9fdf660bc4c0111]
#
# patch "tests/t_existsonpath.at"
# from [4f555bc7a0c0f3d218a445d3fb78cdcf57147345]
# to [984ebe7ce8dbd63cb065fc1fd5f17c16df3c9fb6]
#
# patch "tests/t_lf_crlf.at"
# from [8e233d81e10aa6d9bab1d7bb38ba7f183ad151b2]
# to [19b497fd65b459240b83270df348bab82f09962c]
#
# patch "tests/t_log_outside_workspace.at"
# from [1e6f8f708369425dfb8bf1f06f4b9f283e24de01]
# to [408e3882754be40081c953771285895e36fd2de8]
#
# patch "tests/t_ls_known.at"
# from [99eb14f8f7144c26b858c836b5fcdc355d0a246d]
# to [6c871d99df8c34c37190d281ca538aa5c90e37a4]
#
# patch "tests/t_rename.at"
# from [c237939fa3e27409437b44b2117942e07f05779e]
# to [b95e23675e65c4c3c9bd2b3490d08ce117b11836]
#
# patch "tests/t_restricted_commands_consistent.at"
# from [a8a896d3209ec673f8197488d639226d62b18158]
# to [e11f8aafa55195d6350e35bd53e9fc0e11b0d1d6]
#
# patch "tests/t_singlecvs.at"
# from [3ab763cc4821f58ecc8cea7ff0d1b8f62004c8ad]
# to [d98391bad7a3290996b9a4354e173ccd3277b001]
#
# patch "tests/t_undo_update.at"
# from [85012f2040dd0f9f6aa13b3c748bf38ea9c10fe7]
# to [23512408a71b29946fbeb5b1d5058c6a5f9abd87]
#
# patch "tests/t_update_to_revision.at"
# from [b6f804cced8a6863a91e4fef319b8f427762001e]
# to [5c67e05438436f0e76bbb4b535481cb4b0f5a27d]
#
# patch "tests/t_update_with_pending_add.at"
# from [3d046ef7f426d6e5d89b0423c72242fde52142e4]
# to [af1ac1b21a52bade76fa8fa92cae2c5be1a18321]
#
# patch "tests/t_update_with_pending_drop.at"
# from [af78561aa074371619cdcdd49ec78084dd0ecf0d]
# to [04407e4305991ff2358e52325d584674e8f0fcd2]
#
# patch "tests/t_update_with_pending_rename.at"
# from [c77760a120745388dc4fda95d8d617b7c052ce42]
# to [2577008031f11dbdeaceeda708d4238b5b52c641]
#
# patch "testsuite.at"
# from [c4a1c8a8aa70c27d11caeb9c70ba713680109fee]
# to [9e39ba6a09e3b23919675a2ae8adf1275eac5e08]
#
# patch "work.cc"
# from [f0b8375e1b0bfbaf32770b41ece3015e2a34cb66]
# to [974c1d8a5295fd7317898e60abc636fdcc82ba65]
#
# patch "work.hh"
# from [8c9dc3dba09d6c20d9afb4c9f7c1e11e28e489bb]
# to [723c827976adf80b589df8c0e2629ed7fafb907e]
#
============================================================
--- ChangeLog dc047c34670d6f0a5fa1183eee56574e3ee946db
+++ ChangeLog f1cc93958169d7455c8c6d1b70cef3c744110ab1
@@ -1,3 +1,11 @@
+2006-01-27 Matthew Gregan
+
+ * *: Use the term 'workspace' consistently throughout monotone for
+ the concept we previously described interchangably using the two
+ terms 'working copy' and 'working directory'. This change has
+ been made everywhere except in historical documentation (NEWS and
+ ChangeLog).
+
2006-01-27 Richard Levitte
* monotone.texi (Generating Keys): Correct small type, the keys
============================================================
--- HACKING 9192838166bf96f1f7d8369bc1ac8fcc8dc74be7
+++ HACKING dd8654f0de0f726639e8fc988b30e6ac272c173d
@@ -208,11 +208,11 @@
thrown that will ultimately cause the monotone process to exit. Exceptions
are used (rather than C-style abort() based assertions) so that the stack
will unwind and cause the destructors for objects allocated on the stack to
-run. This allows monotone to leave the user's database and working copy in
+run. This allows monotone to leave the user's database and workspace in
as logical a state as possible. Any in-flight uncommitted database
-transactions will be aborted. Operations occurring on a working copy may
-leave the working copy in an inconsistent state, as we do not have a way to
-atomically update the working copy.
+transactions will be aborted. Operations occurring on a workspace may
+leave the workspace in an inconsistent state, as we do not have a way to
+atomically update the workspace.
Patch submission guidelines
============================================================
--- ROADMAP 53568f4fbd5d01ef09b991793d62f0fd2a0db58f
+++ ROADMAP 745d2ad91a86dc235175a570896ae219fb9853ac
@@ -32,7 +32,7 @@
- modify database code to use sqlite3 pre-parsed queries, blobs
- change netsync to globbing branches, not using collections
- implement improved ACL/permission system for default trust rules
-- implement "merge into working copy" approach to merging
+- implement "merge into workspace" approach to merging
- emacs integration
( probably call it "1.0" or "stable" around here )
============================================================
--- app_state.cc 9457a5a86bf5be3837482583ed08164b53e20541
+++ app_state.cc 18045740e735562c70e3a482927003729014844f
@@ -62,12 +62,12 @@
}
void
-app_state::allow_working_copy()
+app_state::allow_workspace()
{
L(FL("initializing from directory %s\n") % fs::initial_path().string());
- found_working_copy = find_and_go_to_working_copy(search_root);
+ found_workspace = find_and_go_to_workspace(search_root);
- if (found_working_copy)
+ if (found_workspace)
{
read_options();
@@ -95,7 +95,7 @@
L(FL("setting dump path to %s\n") % dump_path);
// the 'true' means that, e.g., if we're running checkout, then it's
// okay for dumps to go into our starting working dir's MT rather
- // than the checked-out dir's MT.
+ // than the new workspace dir's MT.
global_sanity.filename = system_path(dump_path, false);
}
}
@@ -103,29 +103,29 @@
}
void
-app_state::require_working_copy(std::string const & explanation)
+app_state::require_workspace(std::string const & explanation)
{
- N(found_working_copy,
- F("working copy directory required but not found%s%s")
+ N(found_workspace,
+ F("workspace required but not found%s%s")
% (explanation.empty() ? "" : "\n") % explanation);
write_options();
}
void
-app_state::create_working_copy(system_path const & new_dir)
+app_state::create_workspace(system_path const & new_dir)
{
N(!new_dir.empty(), F("invalid directory ''"));
- L(FL("creating working copy in %s\n") % new_dir);
+ L(FL("creating workspace in %s\n") % new_dir);
mkdir_p(new_dir);
- go_to_working_copy(new_dir);
+ go_to_workspace(new_dir);
N(!directory_exists(bookkeeping_root),
F("monotone bookkeeping directory '%s' already exists in '%s'\n")
% bookkeeping_root % new_dir);
- L(FL("creating bookkeeping directory '%s' for working copy in '%s'\n")
+ L(FL("creating bookkeeping directory '%s' for workspace in '%s'\n")
% bookkeeping_root % new_dir);
mkdir_p(bookkeeping_root);
@@ -329,11 +329,11 @@
app_state::make_branch_sticky()
{
options[branch_option] = branch_name();
- if (found_working_copy)
+ if (found_workspace)
{
- // already have a working copy, can (must) write options directly,
+ // already have a workspace, can (must) write options directly,
// because no-one else will do so
- // if we don't have a working copy yet, then require_working_copy (for
+ // if we don't have a workspace yet, then require_workspace (for
// instance) will call write_options when it finds one.
write_options();
}
@@ -498,8 +498,8 @@
return confdir;
}
-// rc files are loaded after we've changed to the working copy directory so
-// that MT/monotonerc can be loaded between ~/.monotone/monotonerc and other
+// rc files are loaded after we've changed to the workspace so that
+// MT/monotonerc can be loaded between ~/.monotone/monotonerc and other
// rcfiles
void
@@ -516,11 +516,11 @@
if (rcfiles)
{
system_path default_rcfile;
- bookkeeping_path working_copy_rcfile;
+ bookkeeping_path workspace_rcfile;
lua.default_rcfilename(default_rcfile);
- lua.working_copy_rcfilename(working_copy_rcfile);
+ lua.workspace_rcfilename(workspace_rcfile);
lua.load_rcfile(default_rcfile, false);
- lua.load_rcfile(working_copy_rcfile, false);
+ lua.load_rcfile(workspace_rcfile, false);
}
// command-line rcfiles override even that
============================================================
--- app_state.hh 2f43fc74c88fdbbfdeeef1c966a2a811ee2e0c20
+++ app_state.hh 7fa51b357c748547e5d71dbc84fb35077c148177
@@ -55,7 +55,7 @@
std::vector extra_rcfiles;
path_set restrictions;
path_set excludes;
- bool found_working_copy;
+ bool found_workspace;
long depth;
long last;
long next;
@@ -88,9 +88,9 @@
std::pair,
boost::shared_ptr > > verifiers;
- void allow_working_copy();
- void require_working_copy(std::string const & explanation = "");
- void create_working_copy(system_path const & dir);
+ void allow_workspace();
+ void require_workspace(std::string const & explanation = "");
+ void create_workspace(system_path const & dir);
void set_restriction(path_set const & valid_paths,
std::vector const & paths);
@@ -98,11 +98,11 @@
bool restriction_includes(split_path const & path);
// Set the branch name. If you only invoke set_branch, the branch
- // name is not sticky (and won't be written to the working copy and
+ // name is not sticky (and won't be written to the workspace and
// reused by subsequent monotone invocations). Commands which
// switch the working to a different branch should invoke
- // make_branch_sticky (before require_working_copy because this
- // function updates the working copy).
+ // make_branch_sticky (before require_workspace because this
+ // function updates the workspace).
void set_branch(utf8 const & name);
void make_branch_sticky();
============================================================
--- automate.cc 0b608759447d6c0c9f4aed5289f60a89decac403
+++ automate.cc 68d579fc833b4a0ec52a0c8e5b130af7517ab7ed
@@ -638,7 +638,7 @@
// Name: inventory
// Arguments: none
// Added in: 1.0
-// Purpose: Prints a summary of every file found in the working copy or its
+// Purpose: Prints a summary of every file found in the workspace or its
// associated base manifest. Each unique path is listed on a line prefixed by
// three status characters and two numeric values used for identifying
// renames. The three status characters are as follows.
@@ -665,7 +665,7 @@
// includes the rest of the line. Directory paths are identified as ending with
// the "/" character, file paths do not end in this character.
//
-// Error conditions: If no working copy book keeping MT directory is found,
+// Error conditions: If no workspace book keeping MT directory is found,
// prints an error message to stderr, and exits with status 1.
static void
@@ -677,7 +677,7 @@
if (args.size() != 0)
throw usage(help_name);
- app.require_working_copy();
+ app.require_workspace();
temp_node_id_source nis;
roster_t base, curr;
@@ -890,7 +890,7 @@
// Name: get_revision
// Arguments:
-// 1: a revision id (optional, determined from working directory if non-existant)
+// 1: a revision id (optional, determined from the workspace if non-existant)
// Added in: 1.0
// Purpose: Prints changeset information for the specified revision id.
//
@@ -942,7 +942,7 @@
revision_set rev;
roster_t old_roster, new_roster;
- app.require_working_copy();
+ app.require_workspace();
get_unrestricted_working_revision_and_rosters(app, rev,
old_roster,
new_roster);
@@ -963,7 +963,7 @@
// Name: get_manifest_of
// Arguments:
-// 1: a revision id (optional, determined from working directory if non-existant)
+// 1: a revision id (optional, determined from the workspace if non-existant)
// Added in: 2.0
// Purpose: Prints the contents of the manifest associated with the given revision ID.
//
@@ -987,7 +987,7 @@
if (args.size() == 0)
{
revision_set rs;
- app.require_working_copy();
+ app.require_workspace();
get_unrestricted_working_revision_and_rosters(app, rs, old_roster, new_roster);
}
else
============================================================
--- commands.cc 7a8a08ebb4f9834aef113c20c529870cb10c5e6b
+++ commands.cc 2f64f75b9afb4a86bac84bcc6cacaba86866be2b
@@ -1164,13 +1164,13 @@
path_set & unknown, path_set & ignored);
-CMD(add, N_("working copy"), N_("[PATH]..."),
- N_("add files to working copy"), OPT_UNKNOWN)
+CMD(add, N_("workspace"), N_("[PATH]..."),
+ N_("add files to workspace"), OPT_UNKNOWN)
{
if (!app.unknown && (args.size() < 1))
throw usage(name);
- app.require_working_copy();
+ app.require_workspace();
path_set paths;
if (app.unknown)
@@ -1192,13 +1192,13 @@
static void find_missing (app_state & app,
vector const & args, path_set & missing);
-CMD(drop, N_("working copy"), N_("[PATH]..."),
- N_("drop files from working copy"), OPT_EXECUTE % OPT_MISSING)
+CMD(drop, N_("workspace"), N_("[PATH]..."),
+ N_("drop files from workspace"), OPT_EXECUTE % OPT_MISSING)
{
if (!app.missing && (args.size() < 1))
throw usage(name);
- app.require_working_copy();
+ app.require_workspace();
path_set paths;
if (app.missing)
@@ -1217,16 +1217,16 @@
ALIAS(rm, drop);
-CMD(rename, N_("working copy"),
+CMD(rename, N_("workspace"),
N_("SRC DEST\n"
"SRC1 [SRC2 [...]] DEST_DIR"),
- N_("rename entries in the working copy"),
+ N_("rename entries in the workspace"),
OPT_EXECUTE)
{
if (args.size() < 2)
throw usage(name);
- app.require_working_copy();
+ app.require_workspace();
file_path dst_path = file_path_external(args.back());
@@ -1291,14 +1291,14 @@
}
-CMD(status, N_("informative"), N_("[PATH]..."), N_("show status of working copy"),
+CMD(status, N_("informative"), N_("[PATH]..."), N_("show status of workspace"),
OPT_DEPTH % OPT_EXCLUDE % OPT_BRIEF)
{
revision_set rs;
roster_t old_roster, new_roster;
data tmp;
- app.require_working_copy();
+ app.require_workspace();
get_working_revision_and_rosters(app, args, rs, old_roster, new_roster);
if (global_sanity.brief)
@@ -1338,7 +1338,7 @@
}
-CMD(identify, N_("working copy"), N_("[PATH]"),
+CMD(identify, N_("workspace"), N_("[PATH]"),
N_("calculate identity of PATH or stdin"),
OPT_NONE)
{
@@ -1370,7 +1370,7 @@
throw usage(name);
if (app.revision_selectors.size() == 0)
- app.require_working_copy();
+ app.require_workspace();
transaction_guard guard(app.db, false);
@@ -1382,7 +1382,7 @@
N(app.db.revision_exists(rid), F("no such revision '%s'") % rid);
// paths are interpreted as standard external ones when we're in a
- // working copy, but as project-rooted external ones otherwise
+ // workspace, but as project-rooted external ones otherwise
file_path fp;
split_path sp;
fp = file_path_external(idx(args, 0));
@@ -1476,7 +1476,7 @@
% ident % app.branch_name);
}
- app.create_working_copy(dir);
+ app.create_workspace(dir);
file_data data;
roster_t ros;
@@ -1649,7 +1649,7 @@
roster_t old_roster, new_roster;
data tmp;
- app.require_working_copy();
+ app.require_workspace();
path_set paths;
get_working_revision_and_rosters(app, args, rs, old_roster, new_roster);
@@ -1682,7 +1682,7 @@
static void
ls_unknown_or_ignored (app_state & app, bool want_ignored, vector const & args)
{
- app.require_working_copy();
+ app.require_workspace();
path_set unknown, ignored;
find_unknown_and_ignored(app, want_ignored, args, unknown, ignored);
@@ -1704,7 +1704,7 @@
cset included_work, excluded_work;
path_set old_paths, new_paths;
- app.require_working_copy();
+ app.require_workspace();
get_base_roster_and_working_cset(app, args, base_rid, base_roster,
old_paths, new_paths,
included_work, excluded_work);
@@ -1747,7 +1747,7 @@
"unknown\n"
"ignored\n"
"missing"),
- N_("show database objects, or the current working copy manifest,\n"
+ N_("show database objects, or the current workspace manifest,\n"
"or unknown, intentionally ignored, or missing state files"),
OPT_DEPTH % OPT_EXCLUDE)
{
@@ -2156,7 +2156,7 @@
throw usage(name);
}
-CMD(attr, N_("working copy"), N_("set PATH ATTR VALUE\nget PATH [ATTR]\ndrop PATH [ATTR]"),
+CMD(attr, N_("workspace"), N_("set PATH ATTR VALUE\nget PATH [ATTR]\ndrop PATH [ATTR]"),
N_("set, get or drop file attributes"),
OPT_NONE)
{
@@ -2166,7 +2166,7 @@
revision_set rs;
roster_t old_roster, new_roster;
- app.require_working_copy();
+ app.require_workspace();
get_unrestricted_working_revision_and_rosters(app, rs, old_roster, new_roster);
file_path path = file_path_external(idx(args,1));
@@ -2275,8 +2275,8 @@
}
-CMD(commit, N_("working copy"), N_("[PATH]..."),
- N_("commit working copy to database"),
+CMD(commit, N_("workspace"), N_("[PATH]..."),
+ N_("commit workspace to database"),
OPT_BRANCH_NAME % OPT_MESSAGE % OPT_MSGFILE % OPT_DATE %
OPT_AUTHOR % OPT_DEPTH % OPT_EXCLUDE)
{
@@ -2287,7 +2287,7 @@
roster_t old_roster, new_roster;
app.make_branch_sticky();
- app.require_working_copy();
+ app.require_workspace();
// preserve excluded work for future commmits
cset excluded_work;
@@ -2647,7 +2647,7 @@
CMD(diff, N_("informative"), N_("[PATH]..."),
N_("show current diffs on stdout.\n"
- "If one revision is given, the diff between the working directory and\n"
+ "If one revision is given, the diff between the workspace and\n"
"that revision is shown. If two revisions are given, the diff between\n"
"them is given. If no format is specified, unified is used by default."),
OPT_REVISION % OPT_DEPTH % OPT_EXCLUDE %
@@ -2671,9 +2671,9 @@
// initialize before transaction so we have a database to work with
if (app.revision_selectors.size() == 0)
- app.require_working_copy();
+ app.require_workspace();
else if (app.revision_selectors.size() == 1)
- app.require_working_copy();
+ app.require_workspace();
if (app.revision_selectors.size() == 0)
{
@@ -2735,7 +2735,7 @@
// Calculate a cset from old->new, then re-restrict it.
// FIXME: this is *possibly* a UI bug, insofar as we
// look at the restriction name(s) you provided on the command
- // line in the context of new and old, *not* the working copy.
+ // line in the context of new and old, *not* the workspace.
// One way of "fixing" this is to map the filenames on the command
// line to node_ids, and then restrict based on those. This
// might be more intuitive; on the other hand it would make it
@@ -2798,12 +2798,12 @@
}
};
-CMD(update, N_("working copy"), "",
- N_("update working copy.\n"
- "This command modifies your working copy to be based off of a\n"
+CMD(update, N_("workspace"), "",
+ N_("update workspace.\n"
+ "This command modifies your workspace to be based off of a\n"
"different revision, preserving uncommitted changes as it does so.\n"
- "If a revision is given, update the working copy to that revision.\n"
- "If not, update the working copy to the head of the branch."),
+ "If a revision is given, update the workspace to that revision.\n"
+ "If not, update the workspace to the head of the branch."),
OPT_BRANCH_NAME % OPT_REVISION)
{
revision_set r_old, r_working, r_new;
@@ -2818,7 +2818,7 @@
if (app.revision_selectors.size() > 1)
throw usage(name);
- app.require_working_copy();
+ app.require_workspace();
// FIXME: the next few lines are a little bit expensive insofar as they
// load the base roster twice. The API could use some factoring or
@@ -2837,7 +2837,7 @@
working_roster, working_mm, app);
N(!null_id(r_old_id),
- F("this working directory is a new project; cannot update"));
+ F("this workspace is a new project; cannot update"));
if (app.revision_selectors.size() == 0)
{
@@ -2870,7 +2870,7 @@
if (r_old_id == r_chosen_id)
{
P(F("already up to date at %s\n") % r_old_id);
- // do still switch the working copy branch, in case they have used
+ // do still switch the workspace branch, in case they have used
// update to switch branches.
if (!app.branch_name().empty())
app.make_branch_sticky();
@@ -2923,7 +2923,7 @@
chosen_uncommon_ancestors.insert(r_target_id);
}
- // Note that under the definition of mark-merge, the working copy is an
+ // Note that under the definition of mark-merge, the workspace is an
// "uncommon ancestor" if itself too, even though it was not present in
// the database (hence not returned by the query above).
@@ -2938,7 +2938,7 @@
roster_t & merged_roster = result.roster;
- content_merge_working_copy_adaptor wca(app, old_roster);
+ content_merge_workspace_adaptor wca(app, old_roster);
resolve_merge_conflicts (r_old_id, r_target_id,
working_roster, target_roster,
working_mm, target_mm,
@@ -2956,11 +2956,11 @@
// chosen --> merged
//
// - old is the revision specified in MT/revision
- // - working is based on old and includes the working copy's changes
+ // - working is based on old and includes the workspace's changes
// - chosen is the revision we're updating to and will end up in MT/revision
// - merged is the merge of working and chosen
//
- // we apply the working to merged cset to the working copy
+ // we apply the working to merged cset to the workspace
// and write the cset from chosen to merged changeset in MT/work
cset update, remaining;
@@ -2972,7 +2972,7 @@
// write_cset(update, t1);
// write_cset(remaining, t2);
// write_manifest_of_roster(merged_roster, t3);
- // P(F("updating working copy with [[[\n%s\n]]]\n") % t1);
+ // P(F("updating workspace with [[[\n%s\n]]]\n") % t1);
// P(F("leaving residual work [[[\n%s\n]]]\n") % t2);
// P(F("merged roster [[[\n%s\n]]]\n") % t3);
// }
@@ -2983,7 +2983,7 @@
// small race condition here...
// nb: we write out r_chosen, not r_new, because the revision-on-disk
- // is the basis of the working copy, not the working copy itself.
+ // is the basis of the workspace, not the workspace itself.
put_revision_id(r_chosen_id);
if (!app.branch_name().empty())
{
@@ -3045,7 +3045,7 @@
P(F("[merged] %s\n") % merged);
left = merged;
}
- P(F("note: your working copies have not been updated\n"));
+ P(F("note: your workspaces have not been updated\n"));
}
CMD(propagate, N_("tree"), N_("SOURCE-BRANCH DEST-BRANCH"),
@@ -3237,8 +3237,8 @@
throw usage(name);
}
-CMD(revert, N_("working copy"), N_("[PATH]..."),
- N_("revert file(s), dir(s) or entire working copy (\".\")"),
+CMD(revert, N_("workspace"), N_("[PATH]..."),
+ N_("revert file(s), dir(s) or entire workspace (\".\")"),
OPT_DEPTH % OPT_EXCLUDE % OPT_MISSING)
{
roster_t old_roster;
@@ -3249,7 +3249,7 @@
if (args.size() < 1 && !app.missing)
throw usage(name);
- app.require_working_copy();
+ app.require_workspace();
get_base_revision(app, old_revision_id, old_roster);
@@ -3427,7 +3427,7 @@
revision_id rid;
if (app.revision_selectors.size() == 0)
- app.require_working_copy();
+ app.require_workspace();
if ((args.size() != 1) || (app.revision_selectors.size() > 1))
throw usage(name);
@@ -3465,7 +3465,7 @@
OPT_LAST % OPT_NEXT % OPT_REVISION % OPT_BRIEF % OPT_DIFFS % OPT_MERGES)
{
if (app.revision_selectors.size() == 0)
- app.require_working_copy("try passing a --revision to start at");
+ app.require_workspace("try passing a --revision to start at");
set nodes;
@@ -3693,7 +3693,7 @@
}
}
-CMD(setup, N_("tree"), N_("[DIRECTORY]"), N_("setup a new working copy directory, default to current"),
+CMD(setup, N_("tree"), N_("[DIRECTORY]"), N_("setup a new workspace directory, default to current"),
OPT_BRANCH_NAME)
{
if (args.size() > 1)
@@ -3708,7 +3708,7 @@
else
dir = ".";
- app.create_working_copy(dir);
+ app.create_workspace(dir);
revision_id null;
put_revision_id(null);
}
============================================================
--- database.cc bfb031cff2341ac7363ac7731326c98aacaa819a
+++ database.cc 430079748f8733f34aa2f781847a905d85983436
@@ -2311,7 +2311,7 @@
vector branch_names;
if (i->second.size() == 0)
{
- __app->require_working_copy("the empty head selector h: refers to the head of the current branch");
+ __app->require_workspace("the empty head selector h: refers to the head of the current branch");
branch_names.push_back((__app->branch_name)());
}
else
@@ -2362,7 +2362,7 @@
L(FL("processing selector type %d with i->second '%s'\n") % ty % i->second);
if ((i->first == selectors::sel_branch) && (i->second.size() == 0))
{
- __app->require_working_copy("the empty branch selector b: refers to the current branch");
+ __app->require_workspace("the empty branch selector b: refers to the current branch");
// FIXME: why do we have to glob on the unbase64(value), rather than being able to use == ?
lim += (boost::format("SELECT id FROM revision_certs WHERE name='%s' AND unbase64(value) glob '%s'")
% branch_cert_name % __app->branch_name).str();
============================================================
--- diff_patch.cc 622032933fcadaeec86c9fd3c90f157d96b3f6e3
+++ diff_patch.cc 62b598d468407c93c6b573a1e7eb97bdd52644c8
@@ -548,15 +548,15 @@
///////////////////////////////////////////////////////////////////////////
-// content_merge_working_copy_adaptor
+// content_merge_workspace_adaptor
///////////////////////////////////////////////////////////////////////////
void
-content_merge_working_copy_adaptor::record_merge(file_id const & left_id,
- file_id const & right_id,
- file_id const & merged_id,
- file_data const & left_data,
- file_data const & merged_data)
+content_merge_workspace_adaptor::record_merge(file_id const & left_id,
+ file_id const & right_id,
+ file_id const & merged_id,
+ file_data const & left_data,
+ file_data const & merged_data)
{
L(FL("temporarily recording merge of %s <-> %s into %s\n")
% left_id % right_id % merged_id);
@@ -565,8 +565,8 @@
}
void
-content_merge_working_copy_adaptor::get_ancestral_roster(node_id nid,
- boost::shared_ptr & anc)
+content_merge_workspace_adaptor::get_ancestral_roster(node_id nid,
+ boost::shared_ptr & anc)
{
// When doing an update, the base revision is always the ancestor to
// use for content merging.
@@ -574,9 +574,9 @@
}
void
-content_merge_working_copy_adaptor::get_version(file_path const & path,
- file_id const & ident,
- file_data & dat)
+content_merge_workspace_adaptor::get_version(file_path const & path,
+ file_id const & ident,
+ file_data & dat)
{
if (app.db.file_version_exists(ident))
app.db.get_file_version(ident, dat);
@@ -585,12 +585,12 @@
data tmp;
file_id fid;
require_path_is_file(path,
- F("file '%s' does not exist in working copy") % path,
- F("'%s' in working copy is a directory, not a file") % path);
+ F("file '%s' does not exist in workspace") % path,
+ F("'%s' in workspace is a directory, not a file") % path);
read_localized_data(path, tmp, app.lua);
calculate_ident(tmp, fid);
N(fid == ident,
- F("file %s in working copy has id %s, wanted %s")
+ F("file %s in workspace has id %s, wanted %s")
% path % fid % ident);
dat = tmp;
}
============================================================
--- diff_patch.hh 094dfdf8f752939ee4dac54366939df07e20898a
+++ diff_patch.hh fb7ab63b1e55fe0278df0c422cd090f555516326
@@ -84,14 +84,14 @@
};
struct
-content_merge_working_copy_adaptor
+content_merge_workspace_adaptor
: public content_merge_adaptor
{
std::map temporary_store;
app_state & app;
boost::shared_ptr base;
- content_merge_working_copy_adaptor (app_state & app,
- boost::shared_ptr base)
+ content_merge_workspace_adaptor (app_state & app,
+ boost::shared_ptr base)
: app(app), base(base)
{}
void record_merge(file_id const & left_ident,
============================================================
--- file_io.hh 78b32a51c65a8e43b200d72c1dc8f6871bb59267
+++ file_io.hh 2082dc3c8480400f32fcbe1c4d881d7512de2204
@@ -82,8 +82,8 @@
// These are not any_path's because we make our write somewhat atomic -- we
// first write to a temp file in MT/ (and it must be in MT/, not like /tmp or
// something, because we can't necessarily atomic rename from /tmp to the
-// working copy). But that means we can't use it in general, only for the
-// working copy.
+// workspace). But that means we can't use it in general, only for the
+// workspace.
void write_data(file_path const & path, data const & data);
void write_data(bookkeeping_path const & path, data const & data);
void write_localized_data(file_path const & path,
============================================================
--- lua.cc c8c228b16b396eaf8cbc1b41ca6363593e9abfee
+++ lua.cc 78722201fdc513bfee248ce6b30b1b1ae593250e
@@ -867,7 +867,7 @@
}
void
-lua_hooks::working_copy_rcfilename(bookkeeping_path & file)
+lua_hooks::workspace_rcfilename(bookkeeping_path & file)
{
file = bookkeeping_root / "monotonerc";
}
============================================================
--- lua.hh 71e2943fa623254b4e3e1340e1f8c4b442271a6c
+++ lua.hh 0d1c63ed6c7b36665ad92780ed88afa1edff3194
@@ -34,7 +34,7 @@
#endif
void set_app(app_state *_app);
void add_std_hooks();
- void working_copy_rcfilename(bookkeeping_path & file);
+ void workspace_rcfilename(bookkeeping_path & file);
void default_rcfilename(system_path & file);
void load_rcfile(utf8 const & file);
void load_rcfile(any_path const & file, bool required);
@@ -89,7 +89,7 @@
std::string const & oldrev,
std::string const & newrev);
- // working copy hooks
+ // workspace hooks
bool hook_use_inodeprints();
// attribute hooks
============================================================
--- merge.hh cd2797de2edf9cc40867385e4a8167be98e7ddfa
+++ merge.hh d8869e646a690f203ff3c85764929d89399f16cd
@@ -16,7 +16,7 @@
// Destructively alter a roster_merge_result to attempt to remove any
// conflicts in it. Takes a content_merge_adaptor to pass on to the content
// merger; used from both the merge-to-database code (below) and the
-// merge-to-working-copy "update" code in commands.cc.
+// merge-to-workspace "update" code in commands.cc.
struct roster_merge_result;
============================================================
--- monotone.1 abc1b6e19fe0af125d2a12299c52e0eedc25989f
+++ monotone.1 f7f22f2d6e5bebf0d526d15651869113fe9c6ead
@@ -33,13 +33,13 @@
Indicate a passing or failing test result on a revision.
.TP
\fBdiff \fI[--revision= [--revision=] ] [...]\fP
-Show diffs between working copy and database.
+Show diffs between workspace and database.
.TP
\fBstatus \fI[...]\fP
-Show status of working copy.
+Show status of workspace.
.TP
\fBlog\fP \fI[id] \fP
-Show historical log of revisions, starting from working copy
+Show historical log of revisions, starting from workspace
base revision, or \fI[id]\fP if given.
.TP
\fBcert\fP \fI [certval]\fP
@@ -68,14 +68,14 @@
List all vars (possibly limited by domain).
.TP
\fBlist unknown \fI[\fP
Write file data packet to stdout.
@@ -130,19 +130,19 @@
Merge unmerged heads of branch.
.TP
\fBadd\fP \fI [...]\fP
-Add files to working copy. adding a file does not copy it into the database,
+Add files to workspace. adding a file does not copy it into the database,
merely adds it to the work list. You must \fBcommit\fP your changes in order
to copy added files to the database.
.TP
\fBdrop\fP \fI [...]\fP
-Drop files from working copy. Files are not deleted from working copy,
+Drop files from workspace. Files are not deleted from workspace,
merely noted as removals in the work list.
.TP
\fBrename\fP \fI \fI\fP
-Rename files from \fI \fP to \fI \fP in working copy.
+Rename files from \fI \fP to \fI \fP in workspace.
.TP
\fBcommit\fP \fI[(--message=|--message-file=)] [...]\fP
-Commit working copy to database. Each commit has a changelog message
+Commit workspace to database. Each commit has a changelog message
associated with it. If --message is provided on the command line, it
is used; if --message-file is provided, the content of the
named file will be used as a commit message. If the filename is '-'
@@ -154,7 +154,7 @@
at all.
.TP
\fBupdate\fP \fI[revision-id]\fP
-Update working copy.
+Update workspace.
.TP
\fBrefresh_inodeprints\fP
Turn on inodeprints mode, and force a cache refresh.
@@ -287,7 +287,7 @@
importing history from another version control system.
.TP
\fB--root=\fI\fP
-Stop the search for a working copy (containing the @file{MT} directory)
+Stop the search for a workspace (containing the @file{MT} directory)
at the specified root directory rather than at the physical root of the
filesystem.
.TP
============================================================
--- monotone.cc 6848daed4195f9d60a08843ac91bdd9e95df2f4f
+++ monotone.cc 92399bda2cd0fba92739636d7b0955c1c43bea23
@@ -70,8 +70,8 @@
{"lca", 0, POPT_ARG_NONE, NULL, OPT_LCA, gettext_noop("use least common ancestor as ancestor for merge"), NULL},
{"execute", 'e', POPT_ARG_NONE, NULL, OPT_EXECUTE, gettext_noop("perform the associated file operation"), NULL},
{"bind", 0, POPT_ARG_STRING, &argstr, OPT_BIND, gettext_noop("address:port to listen on (default :4691)"), NULL},
- {"missing", 0, POPT_ARG_NONE, NULL, OPT_MISSING, gettext_noop("perform the operations for files missing from working directory"), NULL},
- {"unknown", 0, POPT_ARG_NONE, NULL, OPT_UNKNOWN, gettext_noop("perform the operations for unknown files from working directory"), NULL},
+ {"missing", 0, POPT_ARG_NONE, NULL, OPT_MISSING, gettext_noop("perform the operations for files missing from workspace"), NULL},
+ {"unknown", 0, POPT_ARG_NONE, NULL, OPT_UNKNOWN, gettext_noop("perform the operations for unknown files from workspace"), NULL},
{"key-to-push", 0, POPT_ARG_STRING, &argstr, OPT_KEY_TO_PUSH, gettext_noop("push the specified key even if it hasn't signed anything"), NULL},
{"drop-attr", 0, POPT_ARG_STRING, &argstr, OPT_DROP_ATTR, gettext_noop("when rosterifying, drop attrs entries with the given key"), NULL},
{ NULL, 0, 0, NULL, 0, NULL, NULL }
@@ -95,7 +95,7 @@
{"rcfile", 0, POPT_ARG_STRING, &argstr, OPT_RCFILE, gettext_noop("load extra rc file"), NULL},
{"key", 'k', POPT_ARG_STRING, &argstr, OPT_KEY_NAME, gettext_noop("set key for signatures"), NULL},
{"db", 'd', POPT_ARG_STRING, &argstr, OPT_DB_NAME, gettext_noop("set name of database"), NULL},
- {"root", 0, POPT_ARG_STRING, &argstr, OPT_ROOT, gettext_noop("limit search for working copy to specified root"), NULL},
+ {"root", 0, POPT_ARG_STRING, &argstr, OPT_ROOT, gettext_noop("limit search for workspace to specified root"), NULL},
{"verbose", 0, POPT_ARG_NONE, NULL, OPT_VERBOSE, gettext_noop("verbose completion output"), NULL},
{"keydir", 0, POPT_ARG_STRING, &argstr, OPT_KEY_DIR, gettext_noop("set location of key store"), NULL},
{"confdir", 0, POPT_ARG_STRING, &argstr, OPT_CONF_DIR, gettext_noop("set location of configuration directory"), NULL},
@@ -547,11 +547,11 @@
throw usage(cmd); // cmd may be empty, and that's fine.
}
- // at this point we allow a working copy (meaning search for it
+ // at this point we allow a workspace (meaning search for it
// and if found read MT/options) but don't require it. certain
- // commands may subsequently require a working copy or fail
+ // commands may subsequently require a workspace or fail
- app.allow_working_copy();
+ app.allow_workspace();
// main options processed, now invoke the
// sub-command w/ remaining args
============================================================
--- monotone.texi 4c4f7dba85aa2a7d4b5c1d870f5da99046be0ab0
+++ monotone.texi 59eb4911052af4a3a1743caf529acfe14dad092b
@@ -588,7 +588,7 @@
@item
a @i{keystore} in your home directory
@item
-a @i{working copy} in the local file system
+a @i{workspace} in the local file system
@item
a @i{local database} in the local file system
@item
@@ -603,10 +603,10 @@
All information passes @emph{through} your local database, en route to
some other destination. For example, when changes are made in a
-working copy, you may save those changes to your database, and later
+workspace, you may save those changes to your database, and later
you may synchronize your database with someone else's. Monotone will
-not move information directly between a working copy and a remote
-database, or between working copies. Your local database is always
+not move information directly between a workspace and a remote
+database, or between workspaces. Your local database is always
the ``switching point'' for communication.
@ifinfo
@@ -617,11 +617,11 @@
_________/\________
/ \
- +-------------+ +------------+ +--------------+
- | | | | | |
- | remote db | <==> | local db | <==> | working copy |
- | | | | | |
- +-------------+ +------------+ +--------------+
+ +-------------+ +------------+ +-------------+
+ | | | | | |
+ | remote db | <==> | local db | <==> | workspace |
+ | | | | | |
+ +-------------+ +------------+ +-------------+
\________ _______/
\/
@@ -634,32 +634,32 @@
@image{figures/general-workflow}
@end ifnotinfo
-A @dfn{working copy} is a tree of files in your file system, arranged
+A @dfn{workspace} is a tree of files in your file system, arranged
according to the list of file paths and IDs in a particular
manifest. A special directory called @file{MT} exists in the root of
-any working copy. Monotone keeps some special files in the @file{MT}
-directory, in order to track changes you make to your working copy.
+any workspace. Monotone keeps some special files in the @file{MT}
+directory, in order to track changes you make to your workspace.
-Aside from the special @file{MT} directory, a working copy is just a
+Aside from the special @file{MT} directory, a workspace is just a
normal tree of files. You can directly edit the files in a working
copy using a plain text editor or other program; monotone will
automatically notice when you make any changes. If you wish to add
-files, remove files, or move files within your working copy, you must
+files, remove files, or move files within your workspace, you must
tell monotone explicitly what you are doing, as these actions cannot
be deduced.
-If you do not yet have a working copy, you can @dfn{check out} a
-working copy from a database, or construct one from scratch and
+If you do not yet have a workspace, you can @dfn{check out} a
+workspace from a database, or construct one from scratch and
@dfn{add} it into a database. As you work, you will occasionally
address@hidden changes you have made in a working copy to a database,
-and @dfn{update} a working copy to receive changes that have arrived
address@hidden changes you have made in a workspace to a database,
+and @dfn{update} a workspace to receive changes that have arrived
in a database. Committing and updating take place purely between a
-database and a working copy; the network is not involved.
+database and a workspace; the network is not involved.
@ifinfo
@smallexample
@group
- ----------------- check out, working copy
+ ----------------- check out, workspace
( ) or update +----------------
----------------- ----------> |
| | | src/func.c
@@ -689,9 +689,9 @@
A database contains many files, manifests, revisions, and
certificates, some of which are not immediately of interest, some of
which may be unwanted or even false. It is a collection of information
-received from network servers, working copies, and other
+received from network servers, workspaces, and other
databases. You can inspect and modify your databases without affecting
-your working copies, and vice-versa.
+your workspaces, and vice-versa.
Monotone knows how to exchange information in your database with other
remote databases, using an interactive protocol called @dfn{netsync}.
@@ -726,7 +726,7 @@
@itemize
@item
-When you @i{commit} changes from your working copy to your database,
+When you @i{commit} changes from your workspace to your database,
your database stores the changes but does not communicate with the
network. Your commits happen immediately, without consulting any other
party, and do not require network connectivity.
@@ -735,30 +735,30 @@
When you are ready to @i{exchange} work with someone else, you can
push, pull, or sync with other databases on the network. When you talk
to other servers on the network, your database may change, but your
-working copy will not. In fact, you do not need a working copy at all
+workspace will not. In fact, you do not need a workspace at all
when exchanging work.
@item
-When you @i{update} your working copy, some (but not all) of the
+When you @i{update} your workspace, some (but not all) of the
changes which your database received from the network are applied to
-your working copy. The network is not consulted during updates.
+your workspace. The network is not consulted during updates.
@end itemize
The last stage of workflow is worth clarifying: monotone does
@emph{not} blindly apply all changes it receives from a remote
-database to your working copy. Doing so would be very dangerous,
+database to your workspace. Doing so would be very dangerous,
because remote databases are not always trustworthy systems. Rather,
monotone evaluates the certificates it has received along with the
changes, and decides which particular changes are safe and desirable
-to apply to your working copy.
+to apply to your workspace.
You can always adjust the criteria monotone uses to judge the
trustworthiness and desirability of changes in your database. But keep
in mind that it always uses @emph{some} criteria; receiving changes
from a remote server is a @emph{different} activity than applying
-changes to a working copy. Sometimes you may receive changes which
+changes to a workspace. Sometimes you may receive changes which
monotone judges to be untrusted or bad; such changes may stay in your
-database but will @emph{not} be applied to your working copy.
+database but will @emph{not} be applied to your workspace.
Remote databases, in other words, are just untrusted ``buckets'' of
data, which you can trade with promiscuously. There is no trust
@@ -1248,16 +1248,16 @@
@section Starting a New Project
Before he can begin work on the project, Jim needs to create a
address@hidden copy} --- a directory whose contents monotone will keep track
address@hidden --- a directory whose contents monotone will keep track
of. Often, one works on projects that someone else has started, and
-creates working copies with the @code{checkout} command, which you'll
+creates workspaces with the @code{checkout} command, which you'll
learn about later. Jim is starting a new project, though, so he does
something a little bit different. He uses the @code{monotone setup}
-command to create a new working copy.
+command to create a new workspace.
This command creates the named directory (if it doesn't already exist),
and creates the @file{MT} directory within it. The @file{MT} directory
-is how monotone recognizes that a directory is a working copy, and
+is how monotone recognizes that a directory is a workspace, and
monotone stores some bookkeeping files within it. For instance, command
line values for the @option{--db}, @option{--branch} or @option{--key}
options to the @code{setup} command will be cached in a file called
@@ -1266,7 +1266,7 @@
He chooses @code{jp.co.juicebot.jb7} as a branch name. (See
@ref{Naming Conventions} for more information about appropriate branch
-names.) Jim then creates his working copy:
+names.) Jim then creates his workspace:
@smallexample
@group
@@ -1277,8 +1277,8 @@
@end smallexample
Notice that Jim has changed his current directory to his newly created
-working copy. For the rest of this example we will assume that everyone
-issues all further monotone commands from their working copy
+workspace. For the rest of this example we will assume that everyone
+issues all further monotone commands from their workspace
directories.
@page
@@ -1342,14 +1342,14 @@
@smallexample
@group
$ monotone add include/jb.h src
-monotone: adding include/jb.h to working copy add set
-monotone: adding src/apple.c to working copy add set
-monotone: adding src/banana.c to working copy add set
+monotone: adding include/jb.h to workspace add set
+monotone: adding src/apple.c to workspace add set
+monotone: adding src/banana.c to workspace add set
@end group
@end smallexample
This command produces a record of Jim's intentions in a special file
-called @file{MT/work}, stored in the working copy. The file is plain
+called @file{MT/work}, stored in the workspace. The file is plain
text:
@smallexample
@@ -1400,7 +1400,7 @@
constitute only the addition of some files. In the output we can see
one pecularity of monotone's changeset format. The pecularity is that
when monotone records a ``new file'', it actually records two separate
-events: the addition of an empty file to the working copy, and a patch
+events: the addition of an empty file to the workspace, and a patch
of that file from empty to its intended contents.
Jim wants to see the actual details of the files he added, however, so
@@ -1476,7 +1476,7 @@
@section Committing Work
Satisfied with the work he's done, Jim wants to save his changes. He
-then commits his working copy, which causes monotone to process the
+then commits his workspace, which causes monotone to process the
@file{MT/work} file and record the file contents, manifest, and
revision into the database. Since he provided a branch name when he
ran @command{setup}, monotone will use this as the default branch name
@@ -1493,7 +1493,7 @@
When monotone committed Jim's revision, erased the @file{MT/work} file,
and wrote a new file called @file{MT/revision}, which contains the
-working copy's new base revision ID. Jim can use this revision ID in the
+workspace's new base revision ID. Jim can use this revision ID in the
future, as an argument to the @command{checkout} command, if he wishes
to return to this revision:
@@ -1701,7 +1701,7 @@
Abe now has, in his database, a copy of everything Jim put in the
branch. Therefore Abe can disconnect from the expensive network
connection he's on and work locally for a while. Remember that, in
-monotone, work is done between working directories in the filesystem and
+monotone, work is done between workspaces in the filesystem and
the local database; network connectivity is necessary only when that
work is to be shared with others.
@@ -1729,7 +1729,7 @@
Abe decides to do some work on his part of the code. He has a copy of
Jim's database contents, but cannot edit any of that data yet. He
begins his editing by checking out the head of the
address@hidden branch into a working copy, so he can edit
address@hidden branch into a workspace, so he can edit
it:
@smallexample
@@ -1971,7 +1971,7 @@
use too much CPU time, and must be rewritten to use the JuiceBot's
interrupt system. Beth wakes up first and begins working immediately,
basing her work off the revision 80ef9... which is currently in her
-working copy:
+workspace:
@smallexample
@group
@@ -2037,7 +2037,7 @@
Unfortunately, before Beth managed to sync with Jim, Abe had woken up
and implemented a similar interrupt-based apple juice dispenser, but
-his working copy is 70dec..., which is still ``upstream'' of
+his workspace is 70dec..., which is still ``upstream'' of
Beth's.
@smallexample
@@ -2094,7 +2094,7 @@
monotone: common ancestor 70decb4b31a8227a629c0e364495286c5c75f979 abe@@juicebot.co.jp 2004-10-26T:02:50:01 found
monotone: trying 3-way merge
monotone: [merged] da499b9d9465a0e003a4c6b2909102ef98bf4e6d
-monotone: your working copies have not been updated
+monotone: your workspaces have not been updated
@end group
@end smallexample
@@ -2106,7 +2106,7 @@
resolve it.
After merging, the branch has a single head again, and Jim updates
-his working copy.
+his workspace.
@smallexample
@group
@@ -2119,9 +2119,9 @@
@end smallexample
The update command selected an update target --- in this case the newly merged
-head --- and performed an in-memory merge between Jim's working copy
-and the chosen target. The result was then written to Jim's working copy. If
-Jim's working copy had any uncommitted changes in it, they would have been
+head --- and performed an in-memory merge between Jim's workspace
+and the chosen target. The result was then written to Jim's workspace. If
+Jim's workspace had any uncommitted changes in it, they would have been
merged with the update in exactly the same manner as the merge of multiple
committed heads.
@@ -2132,7 +2132,7 @@
committing, then even if the merge somehow fails (due to difficulty in a
manual merge step, for instance), your committed state is still safe.
If you update, on the other hand, you are requesting that monotone
-directly modify your working copy, and while monotone will try hard not
+directly modify your workspace, and while monotone will try hard not
to break anything, this process is inherently more open to error. It is
therefore recommended that you commit your work @emph{first}, before
merging.
@@ -2142,7 +2142,7 @@
@emph{required} to update, and risk the above problems, before you can
commit. Monotone, however, was designed with this problem in mind, and
thus @emph{always} allows you to commit before merging. A good rule of
-thumb is to only use @command{update} in working copies with no local
+thumb is to only use @command{update} in workspaces with no local
modifications, or when you actually want to work against a different
base revision (perhaps because finishing your change turns out to
require some fixes made in another revision, or because you discover
@@ -2192,7 +2192,7 @@
That's all there is to it --- there is now a
@code{jp.co.juicebot.jb7.muffins} branch, with her initial checkin on
-it. She can make further checkins from the same working copy, and they
+it. She can make further checkins from the same workspace, and they
will automatically go to the muffins branch; if anyone else wants to
help her work on muffins, they can check out that branch as usual.
@@ -2511,9 +2511,9 @@
@menu
* Selectors:: Selecting revisions by certificate.
-* Restrictions:: Limit working copy changes to specified files.
+* Restrictions:: Limit workspace changes to specified files.
* Scripting:: Running monotone from other programs.
-* Inodeprints:: Trading off safety for speed in your working copy.
+* Inodeprints:: Trading off safety for speed in your workspace.
* Quality Assurance:: Integrating testing and review with development.
* Vars:: Simple per-database configuration information.
* Reserved Files:: File names with special meanings.
@@ -2585,14 +2585,14 @@
Uses selector type @code{b}. For example, @code{b:net.venge.monotone} matches
@code{branch} certs where the cert value is @code{net.venge.monotone}.
Values to match for can have shell wildcards. If you give a bare @code{b:}
-monotone will require you to be in a working copy, and will use the branch
+monotone will require you to be in a workspace, and will use the branch
value recorded in your MT/options file.
@item Heads selection
Uses selector type @code{h}. For example, @code{h:net.venge.monotone} matches
@code{branch} certs where the cert value is @code{net.venge.monotone} and
the associated revision is a head revision on that branch. Values to match
for can have shell wildcards like the branch selector. If you give a bare
address@hidden:} monotone will require you to be in a working copy, and use the branch
address@hidden:} monotone will require you to be in a workspace, and use the branch
recorded in your MT/options file.
@item Date selection
Uses selector type @code{d}. For example, @code{d:2004-04} matches
@@ -2692,7 +2692,7 @@
Several monotone commands accept optional @var{pathname...} arguments in
order to establish a ``restriction''. Restrictions are used to limit
the files and directories these commands examine for changes when
-comparing the working copy to the revision it is based on. Restricting a
+comparing the workspace to the revision it is based on. Restricting a
command to a specified set of files or directories simply ignores
changes to files or directories not included by the restriction.
@@ -2724,14 +2724,14 @@
The @command{update} command does not allow for updates to a
restricted set of files, which may be slightly different than other
version control systems. Partial updates don't really make sense in
-monotone, as they would leave the working copy based on a revision that
+monotone, as they would leave the workspace based on a revision that
doesn't exist in the database, starting an entirely new line of
development.
@heading Subdirectory restrictions
The restrictions facility also allows commands to operate from within a
-subdirectory of the working copy. By default, the @i{entire working
+subdirectory of the workspace. By default, the @i{entire working
copy} is always examined for changes. However, specifying an explicit
"." pathname to a command will restrict it to the current subdirectory.
Note that this is quite different from other version control systems and
@@ -2744,34 +2744,34 @@
operate on the whole tree.
This default was chosen because monotone versions whole project trees
-and generally expects to commit all changes in the working copy as a
+and generally expects to commit all changes in the workspace as a
single atomic unit. Other version control systems often version
individual files or directories and may not support atomic commits at
all.
-When working from within a subdirectory of the working copy all
+When working from within a subdirectory of the workspace all
paths specified to monotone commands must be relative to the current
subdirectory.
address@hidden Finding a working copy
address@hidden Finding a workspace
Monotone only stores a single @file{MT} directory at the root of a
-working copy. Because of this, a search is done to find the @file{MT}
+workspace. Because of this, a search is done to find the @file{MT}
directory in case a command is executed from within a subdirectory of a
-working copy. Before a command is executed, the search for a working
+workspace. Before a command is executed, the search for a working
copy directory is done by traversing parent directories until an
@file{MT} directory is found or the filesystem root is reached. Upon
finding an @file{MT} directory, the @file{MT/options} file is read for
default options. The @option{--root} option may be used to stop the
search early, before reaching the root of the physical filesystem.
-Many monotone commands don't require a working copy and will simply
+Many monotone commands don't require a workspace and will simply
proceed with no default options if no @file{MT} directory is found.
-However, some monotone commands do require a working copy and will fail
+However, some monotone commands do require a workspace and will fail
if no @file{MT} directory can be found.
The @command{checkout} and @command{setup} commands create a @i{new
-working copy} and initialize a new @file{MT/options} file based on their
+workspace} and initialize a new @file{MT/options} file based on their
current option settings.
@@ -2805,12 +2805,12 @@
@section Inodeprints
Fairly often, in order to accomplish its job, monotone has to look at
-your working copy and figure out what has been changed in it since your
+your workspace and figure out what has been changed in it since your
last commit. Commands that do this include @command{status},
@command{diff}, @command{update}, @command{commit}, and others. There
are two different techniques it can use to do this. The default, which
is sufficient for most projects, is to simply read every file in the
-working copy, compute their @sc{sha1} hash, and compare them to the
+workspace, compute their @sc{sha1} hash, and compare them to the
hashes monotone has stored. This is very safe and reliable, and turns
out to be fast enough for most projects. However, on very large
projects, ones whose source trees are many megabytes in size, it can
@@ -2818,7 +2818,7 @@
The other technique, known as @emph{inodeprints}, is designed for this
situation. When running in inodeprints mode, monotone does not read the
-whole working copy; rather, it keeps a cache of interesting information
+whole workspace; rather, it keeps a cache of interesting information
about each file (its size, its last modification time, and so on), and
skips reading any file for which these values have not changed. This is
inherently somewhat less safe, and, as mentioned above, unnecessary for
@@ -2832,10 +2832,10 @@
the @file{MT/inodeprints} file; monotone uses it only as a cache and
will continue to operate correctly.
-Normally, instead of enabling this up on a per-working-copy basis, you
+Normally, instead of enabling this up on a per-workspace basis, you
will want to simply define the @code{use_inodeprints} hook to return
@code{true}; this will automatically enable inodeprints mode in any new
-working copies you create. See @ref{Hook Reference} for details.
+workspaces you create. See @ref{Hook Reference} for details.
@page
@node Quality Assurance
@@ -2859,7 +2859,7 @@
the ``heads'' of a subgraph, which is the subgraph's set of nodes with
no descendents. For example, when you run the @code{update} command,
monotone searches the subgraph consisting of descendents of the base
-revision of the current working copy, trying to locate a unique head to
+revision of the current workspace, trying to locate a unique head to
update the base revision to.
Monotone's quality assurance mechanisms are mostly based on
@@ -2893,7 +2893,7 @@
the @code{testresult} certs present on the source and proposed
destination of an update. Only if the change in test results are
deemed ``acceptable'' does monotone actually select an update target
-to merge into your working copy.
+to merge into your workspace.
For details on these hooks, see the @ref{Hook Reference}.
@@ -2905,7 +2905,7 @@
Vars are simple configuration variables that monotone refers to in some
circumstances; they are used for configuration that monotone needs to be
able to modify itself, and that should be per-database (rather than
-per-user or per-working copy, both of which are supported by
+per-user or per-workspace, both of which are supported by
@file{monotonerc} scripts). Vars are local to a database, and never
transferred by netsync.
@@ -2957,7 +2957,7 @@
@node Reserved Files
@section Reserved Files
-A monotone working copy consists of control files and non-control
+A monotone workspace consists of control files and non-control
files. Each type of file can be versioned or non-versioned. These
classifications lead to four groups of files:
@@ -2973,15 +2973,15 @@
their state tracked as they are modified.
If a control file is versioned, it is considered @emph{part of} the
-state of the working copy, and will be recorded as a manifest
+state of the workspace, and will be recorded as a manifest
entry. If a control file is not versioned, it is used to @emph{manage}
-the state of the working copy, but it not considered an intrinsic part
+the state of the workspace, but it not considered an intrinsic part
of it.
Most files you manage with monotone will be versioned non-control
files. For example, if you keep source code or documents in a monotone
database, they are versioned non-control files. Non-versioned,
-non-control files in your working copy are generally temporary or junk
+non-control files in your workspace are generally temporary or junk
files, such as backups made by editors or object files made by
compilers. Such files are ignored by monotone.
@@ -3015,17 +3015,17 @@
will only select revisions that do not have regressions according to the given
testresult keys.
@item MT/revision
-Contains the identity of the ``base'' revision of the working copy.
-Each working copy has a base revision. When the working copy is
+Contains the identity of the ``base'' revision of the workspace.
+Each workspace has a base revision. When the workspace is
committed, the base revision is considered to be the ancestor of the
committed revision.
@item MT/options
Contains ``sticky'' command-line options such as @option{--db} or
@option{--branch}, such that you do not need to enter them repeatedly
-after checking out a particular working copy.
+after checking out a particular workspace.
@item MT/work
Contains a list of additions, deletions, and renames which have occurred
-in the current working copy, relative to the base version.
+in the current workspace, relative to the base version.
@item MT/log
Contains log messages to append to the ``changelog'' cert upon
commit. The user may add content to this file while they work. Upon a
@@ -3146,14 +3146,14 @@
Monotone contains a mechanism for storing @dfn{persistent file
attributes}. These differ from file certificates in an important way:
-attributes are associated with a path name in your working copy,
+attributes are associated with a path name in your workspace,
rather than a particular version of a file. Otherwise they are
similar: a file attribute associates a simple name/value pair with a
-file in your working copy.
+file in your workspace.
The attribute mechanism is motivated by the fact that some people like
to store executable programs in version control systems, and would like
-the programs to remain executable when they check out a working copy.
+the programs to remain executable when they check out a workspace.
For example, the @code{configure} shell script commonly shipped with
many programs should be executable.
@@ -3163,7 +3163,7 @@
Rather than try to extend the manifest file format to accommodate
attributes, monotone requires that you place your attributes in a
-specially named file in the root of your working copy. The file is
+specially named file in the root of your workspace. The file is
called @file{.mt-attrs}, and it has a simple stanza-based format, for
example:
@@ -3179,7 +3179,7 @@
@end smallexample
Each stanze of the @file{.mt-attrs} file assigns attributes to a file in
-your working copy. The first line of each stanza is @code{file}
+your workspace. The first line of each stanza is @code{file}
followed by the quoted name of the file you want to assign attributes
to. Each subsequent line is the name of an attribute, followed by a
quoted value for that attribute. Stanzas are separated by blank lines.
@@ -3191,7 +3191,7 @@
attributes by defining hooks; see the @code{attr_functions} entry in
@ref{Hook Reference}.
-Every time your working copy is written to, monotone will look for the
+Every time your workspace is written to, monotone will look for the
@file{.mt-attrs} file, and if it exists, run the corresponding hooks
registered for each attribute found in the file. This way, you can
extend the vocabulary of attributes understood by monotone simply by
@@ -3200,9 +3200,9 @@
Aside from its special interpretation, the @file{.mt-attrs} file is a
normal text file. If you want other people to see your attributes, you
should @code{add} and @code{commit} the @file{.mt-attrs} file in your
-working copy. If you make changes to it which conflict with changes
+workspace. If you make changes to it which conflict with changes
other people make, you will have to resolve those conflicts, as plain
-text, just as with any other text file in your working copy.
+text, just as with any other text file in your workspace.
@page
@node Merging
@@ -3358,7 +3358,7 @@
@end multitable
The CVS command contacts a network server, retrieves a revision, and
-stores it in your working copy. There are two cosmetic differences
+stores it in your workspace. There are two cosmetic differences
with the monotone command: remote databases are specified by hostnames
and globs, and revisions are denoted by @sc{sha1} values (or
selectors).
@@ -3479,7 +3479,7 @@
Monotone's @command{diff} command is modeled on that of CVS, so the
main features are the same: @command{diff} alone prints the
-differences between your working copy and its base revision, whereas
+differences between your workspace and its base revision, whereas
@command{diff} accompanied by two revision numbers prints the
difference between those two revisions. The major difference between
CVS and monotone here is that monotone's revision numbers are
@@ -3549,7 +3549,7 @@
@end smallexample
@end multitable
-Monotone does not require that you erase a file from the working copy
+Monotone does not require that you erase a file from the workspace
before you drop it. Dropping a file merely removes its entry in the
manifest of the current revision unless you give it the @command{--execute}
flag, which tells monotone to go ahead and also remove it from the filesystem.
@@ -3596,7 +3596,7 @@
@end multitable
The @command{setup} command turns an ordinary directory into a
-monotone working copy. After that, you can add your files and commit
+monotone workspace. After that, you can add your files and commit
them as usual.
@heading Initializing a Repository
@@ -3630,7 +3630,7 @@
@menu
* Tree:: Operations on tree states in your database
-* Working Copy:: Operations on your working copy
+* Working Copy:: Operations on your workspace
* Network:: Communication with the network
* Informative:: Production of descriptive reports
* Key and Cert:: General operations on keys or certificates
@@ -3654,7 +3654,7 @@
Without a @option{--revision} argument, the command outputs the
contents of @var{path} as found in the current revision. This requires
-the command be executed from within a working copy.
+the command be executed from within a workspace.
With an explicit @option{--revision} argument, the command outputs
contents of @var{path} at that revision.
@@ -3794,7 +3794,7 @@
@ftable @command
@item monotone setup address@hidden
-This command prepares @var{directory} as a monotone working directory,
+This command prepares @var{directory} as a monotone workspace,
by creating and populating the @file{MT} directory with basic
information. This information must include at least the branch and the
database to be used, both of which will be placed in the
@@ -3809,8 +3809,8 @@
@item monotone add @var{pathname...}
@item monotone add --unknown
This command places ``add'' entries for the paths specified in
address@hidden in the working copy's ``work list''. The work list
-of your working copy is located at @file{MT/work}, and is a list of
address@hidden in the workspace's ``work list''. The work list
+of your workspace is located at @file{MT/work}, and is a list of
explicit pathname changes you wish to commit at some future time, such
as addition, removal or renaming of files.
@@ -3820,7 +3820,7 @@
While this command places an ``add'' entry on your work list, it does
not immediately affect your database. When you @command{commit} your
-working copy, monotone will use the work list to build a new revision,
+workspace, monotone will use the work list to build a new revision,
which it will then commit to the database. The new revision will have
any added entries inserted in its manifest.
@@ -3828,8 +3828,8 @@
@item monotone drop @var{pathname...}
@itemx monotone drop --missing
This command places ``drop'' entries for the paths specified in
address@hidden in the working copy's ``work list''. The work list of
-your working copy is located at @file{MT/work}, and is a list of
address@hidden in the workspace's ``work list''. The work list of
+your workspace is located at @file{MT/work}, and is a list of
explicit pathname changes you wish to commit at some future time, such
as addition, removal, or renaming of files. This command also removes
any attributes on @var{pathname}; see @ref{File Attributes} for more
@@ -3840,7 +3840,7 @@
While this command places a ``drop'' entry on your work list, it does
not immediately affect your database. When you @command{commit} your
-working copy, monotone will use the work list to build a new revision,
+workspace, monotone will use the work list to build a new revision,
which it will then commit to the database. The new revision will have
any dropped entries removed from its manifest.
@@ -3852,9 +3852,9 @@
@item monotone [--execute] rename @var{src} @var{dst}
@itemx monotone [--execute] rename @var{src1} @var{...} @var{dst/}
This command places ``rename'' entries for the paths specified in
address@hidden and @var{dst} in the working copy's ``work list''. The second form
address@hidden and @var{dst} in the workspace's ``work list''. The second form
renames a number of source paths to the given destination. The work
-list of your working copy is located at @file{MT/work}, and is a list of
+list of your workspace is located at @file{MT/work}, and is a list of
explicit pathname changes you wish to commit at some future time, such
as addition, removal, or renaming of files. This command also moves any
attributes on @var{src} to @var{dst}; see @ref{File Attributes} for more
@@ -3862,7 +3862,7 @@
While this command places a ``rename'' entry on your work list, it
does not immediately affect your database. When you @command{commit}
-your working copy, monotone will use the work list to build a new
+your workspace, monotone will use the work list to build a new
revision, which it will then commit to the database. The new revision
will have any renamed entries in its manifest adjusted to their new
names.
@@ -3878,12 +3878,12 @@
@itemx monotone commit address@hidden @var{pathname...}
@itemx monotone commit address@hidden @var{pathname...}
-This command looks at your working copy, decides which files have
+This command looks at your workspace, decides which files have
changed, and saves the changes to your database. It does this by loading
the revision named in the @file{MT/revision} file, locating the base
-manifest for your working copy, applying any changes described in the
+manifest for your workspace, applying any changes described in the
@file{MT/work} file, and then comparing the updated base manifest to the
-files it finds in your working copy, to determine which files have been
+files it finds in your workspace, to determine which files have been
edited.
For each edited file, a delta is copied into the database. Then the
@@ -3895,15 +3895,15 @@
Specifying pathnames to @command{commit} restricts the set of changes
that are visible and results in only a partial commit of the working
copy. Changes to files not included in the specified set of pathnames
-will be ignored and will remain in the working copy until they are
+will be ignored and will remain in the workspace until they are
included in a future commit. With a partial commit, only the relevant
entries in the @file{MT/work} file will be removed and other entries
will remain for future commits.
-From within a subdirectory of the working copy the @command{commit}
+From within a subdirectory of the workspace the @command{commit}
command will, by default, include @emph{all changes} in the working
copy. Specifying only the pathname "." will restrict @command{commit}
-to files changed within the current subdirectory of the working copy.
+to files changed within the current subdirectory of the workspace.
The @option{--message} and @option{--message-file} options are mutually
exclusive. Both provide a @var{logmsg} describing the commit.
@@ -3911,7 +3911,7 @@
the log message, while @option{--message} provides it directly.
The @file{MT/log} file can be edited by the user during their daily work
-to record the changes made to the working copy. When running the
+to record the changes made to the workspace. When running the
@command{commit} command without a @var{logmsg} supplied, the contents
of the @file{MT/log} file will be read and passed to the Lua hook
@code{edit_comment} as a second parameter named @var{user_log_content}.
@@ -3920,7 +3920,7 @@
If a @option{--branch} option is specified, the @command{commit} command
commits to this branch (creating it if necessary). The branch becomes
-the new default branch of the working copy.
+the new default branch of the workspace.
The @command{commit} command also synthesizes a number of
certificates, which it attaches to the new manifest version and copies
@@ -3952,22 +3952,22 @@
@item monotone revert @var{pathname...}
@itemx monotone revert --missing @var{pathname...}
-This command changes your working copy, so that changes you have made
+This command changes your workspace, so that changes you have made
since the last checkout or update are discarded. The command is
restricted the set of files or directories given as arguments. To
-revert the entire working copy, use @command{revert} "." in the
+revert the entire workspace, use @command{revert} "." in the
top-level directory. Specifying "." in a subdirectory will restrict
@command{revert} to files changed within the current subdirectory.
If the flag @option{--missing} is given it reverts (ie, restores) any
files which monotone has listed in its manifest, but which have been
-deleted from the working copy. Only missing files matching the given
+deleted from the workspace. Only missing files matching the given
file or directory arguments are reverted.
@item monotone update
@itemx monotone update address@hidden
Without a @option{--revision} argument, this command incorporates
-``recent'' changes found in your database into your working copy. It
+``recent'' changes found in your database into your workspace. It
does this by performing 3 separate stages. If any of these stages
fails, the update aborts, doing nothing. The stages are:
@@ -3981,7 +3981,7 @@
certificates. From the remaining candidates, select the deepest child
by ancestry and call it the ``target'' of the update.
@item
-Merge the target of the update with the working copy, in memory, and
+Merge the target of the update with the workspace, in memory, and
if the merge is successful, write the result over top of the working
copy.
@end itemize
@@ -3990,7 +3990,7 @@
as the update target instead of finding an acceptable candidate.
The effect is always to take whatever changes you have made in the
-working copy, and to ``transpose'' them onto a new revision, using
+workspace, and to ``transpose'' them onto a new revision, using
monotone's 3-way merge algorithm to achieve good results. Note that
with the explicit @option{--revision} argument, it is possible to update
``backwards'' or ``sideways'' in history --- for example, reverting to
@@ -4001,13 +4001,13 @@
If a @option{--branch} option is specified, the @command{update} command
tries to select the revision to update to from this branch. The branch
-becomes the new default branch of the working copy (even if you also
+becomes the new default branch of the workspace (even if you also
specify an explicit @option{--revision} argument).
@item monotone refresh_inodeprints
-This command puts the current working copy into @ref{Inodeprints} mode,
+This command puts the current workspace into @ref{Inodeprints} mode,
if it was not already, and forces a full inodeprints cache refresh.
-After running this command, you are guaranteed that your working copy is
+After running this command, you are guaranteed that your workspace is
in inodeprints mode, and that the inodeprints cache is accurate and up
to date.
@@ -4108,18 +4108,18 @@
@item monotone status
@itemx monotone status @var{pathname...}
-This command prints a description of the ``status'' of your working copy.
+This command prints a description of the ``status'' of your workspace.
In particular, it prints:
@itemize
@item
The ``base revision ID'' and ``base manifest ID'', which are
-referenced by the file @file{MT/revision}, and which your working copy
+referenced by the file @file{MT/revision}, and which your workspace
is an in-progress descendent of.
@item
The ``current manifest ID'', which is the ID of the manifest which
results from applying @file{MT/work} to the base manifest, and
updating any @sc{sha1} values of files to reflect changes you have
-made to the working copy. In other words, the current manifest ID is
+made to the workspace. In other words, the current manifest ID is
the ID which would accompany any revision you would commit, if you ran
@command{monotone commit}.
@item
@@ -4129,13 +4129,13 @@
Specifying optional @var{pathname...} arguments to the @command{status}
command restricts the set of changes that are visible and results in
-only a partial status of the working copy. Changes to files not included
+only a partial status of the workspace. Changes to files not included
in the specified set of pathnames will be ignored.
-From within a subdirectory of the working copy the @command{status}
+From within a subdirectory of the workspace the @command{status}
command will, by default, include @emph{all changes} in the working
copy. Specifying only the pathname "." will restrict @command{status}
-to files changed within the current subdirectory of the working copy.
+to files changed within the current subdirectory of the workspace.
@item monotone log
@itemx monotone log address@hidden address@hidden [...]] [--brief] [--merges] address@hidden [...]]
@@ -4157,7 +4157,7 @@
If one or more revision IDs are given, the command starts tracing back
through history from these revisions, otherwise it starts from the base
-revision of your working copy.
+revision of your workspace.
If one or more files are given, the command will only log the revisions
where those files are changed.
@@ -4225,13 +4225,13 @@
These commands print out GNU ``unified diff format'' textual difference
listings between various manifest versions. With no @option{--revision}
options, @command{diff} will print the differences between the
-base revision and the current revision in the working copy.
+base revision and the current revision in the workspace.
With one @option{--revision} option, @command{diff} will print the
differences between the revision @var{id} and the current revision in
-the working copy. With two @option{--revision} options @command{diff}
+the workspace. With two @option{--revision} options @command{diff}
will print the differences between revisions @var{id1} and @var{id2},
-ignoring any working copy.
+ignoring any workspace.
In all cases, monotone will print a textual summary -- identical to
the summary presented by @command{monotone status} -- of the logical
@@ -4244,10 +4244,10 @@
two revisions. Changes to files not included in the specified set of
pathnames will be ignored.
-From within a subdirectory of the working copy the @command{diff}
+From within a subdirectory of the workspace the @command{diff}
command will, by default, include @emph{all changes} in the working
copy. Specifying only the pathname "." will restrict @command{diff}
-to files changed within the current subdirectory of the working copy.
+to files changed within the current subdirectory of the workspace.
The output format of @command{diff} is controlled by the options
@option{--unified}, @option{--context}, and @option{--external}.
@@ -4349,36 +4349,36 @@
@itemx monotone list known @var{pathname...}
This command lists all files which would become part of the manifest of
-the next revision if you comitted your working copy at this point.
+the next revision if you comitted your workspace at this point.
Specifying pathnames to the @command{list known} command restricts
the set of paths that are searched for manifest files. Files not
included in the specified set of pathnames will not be listed.
-From within a subdirectory of the working copy the @command{list
-known} command will, by default, search the entire working copy.
+From within a subdirectory of the workspace the @command{list
+known} command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for known
-files to the current subdirectory of the working copy.
+files to the current subdirectory of the workspace.
@item monotone list unknown
@itemx monotone list unknown @var{pathname...}
-This command lists all files in your working copy that monotone is
+This command lists all files in your workspace that monotone is
either ignoring or knows nothing about.
Specifying pathnames to the @command{list unknown} command restricts the
set of paths that are searched for unknown files. Unknown files not
included in the specified set of pathnames will not be listed.
-From within a subdirectory of the working copy the @command{list
-unknown} command will, by default, search the entire working copy.
+From within a subdirectory of the workspace the @command{list
+unknown} command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for unknown
-files to the current subdirectory of the working copy.
+files to the current subdirectory of the workspace.
@item monotone list ignored
@itemx monotone list ignored @var{pathname...}
-This command lists all files in your working copy that monotone is
+This command lists all files in your workspace that monotone is
intentionally ignoring, due to the results of the @code{ignore_file
(@var{filename})} hook.
@@ -4386,25 +4386,25 @@
set of paths that are searched for ignored files. Ignored files not
included in the specified set of pathnames will not be listed.
-From within a subdirectory of the working copy the @command{list
-ignored} command will, by default, search the entire working copy.
+From within a subdirectory of the workspace the @command{list
+ignored} command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for ignored
-files to the current subdirectory of the working copy.
+files to the current subdirectory of the workspace.
@item monotone list missing
@itemx monotone list missing @var{pathname...}
-This command lists all files in your working copy's base manifest,
-which are not present in the working copy.
+This command lists all files in your workspace's base manifest,
+which are not present in the workspace.
Specifying pathnames to the @command{list missing} command restricts the
set of paths that are searched for missing files. Missing files not
included in the specified set of pathnames will not be listed.
-From within a subdirectory of the working copy the @command{list
-missing} command will, by default, search the entire working copy.
+From within a subdirectory of the workspace the @command{list
+missing} command will, by default, search the entire workspace.
Specifying only the pathname "." will restrict the search for missing
-files to the current subdirectory of the working copy.
+files to the current subdirectory of the workspace.
@end ftable
@@ -4478,7 +4478,7 @@
This command is a synonym for @code{monotone cert @var{id} branch
@var{branchname}} where @var{branchname} is the current branch name
-(either deduced from the working copy or from the @option{--branch}
+(either deduced from the workspace or from the @option{--branch}
option).
@@ -5338,7 +5338,7 @@
@item Purpose:
-Prints the inventory of every file found in the working copy or its
+Prints the inventory of every file found in the workspace or its
associated base manifest. Each unique path is listed on a line prefixed by
three status characters and two numeric values used for identifying
renames.
@@ -5390,7 +5390,7 @@
@end verbatim
Recorded the rotation of files @file{foo} -> @file{bar} -> @file{baz} ->
address@hidden, but the actual files in the working directory were not
address@hidden, but the actual files in the workspace were not
moved, so monotone interprets all files as having been patched:
@verbatim
@@ -5555,7 +5555,7 @@
@item Error conditions:
-When executed from outside of a working copy directory, prints an error
+When executed from outside of a workspace directory, prints an error
message to stderr, and exits with status 1.
@end table
@@ -5719,7 +5719,7 @@
Specifying the option @var{id} argument outputs the changeset
information for the specified @var{id}. Otherwise, @var{id} is
-determined from the working directory.
+determined from the workspace.
@item Added in:
@@ -5804,7 +5804,7 @@
Specifying the optional @var{revid} argument outputs the manifest for the
revision with the specified ID. Otherwise, outputs the manifest for the
-current working directory. (You can think of leaving the argument blank
+current workspace. (You can think of leaving the argument blank
as meaning ``give me the manifest of THIS''.)
@item Added in:
@@ -5991,7 +5991,7 @@
execute it. This way you can modify how monotone behaves.
You can put new definitions for any of these hook functions in a file
address@hidden/.monotone/monotonerc}, or in your working copy in
address@hidden/.monotone/monotonerc}, or in your workspace in
@file{MT/monotonerc}, both of which will be read every time monotone
runs. Definitions in @file{MT/monotonerc} shadow (override)
definitions made in your @file{$HOME/.monotone/monotonerc}. You can also tell
@@ -6180,7 +6180,7 @@
@item use_inodeprints ()
Returns @code{true} if you want monotone to automatically enable
address@hidden support in all working copies. Only affects working
address@hidden support in all workspaces. Only affects working
copies created after you modify the hook.
The default definition of this hook is:
@@ -6312,7 +6312,7 @@
make which kinds of assertions using certs. Monotone these certs when
selecting available revisions for commands such as @command{update}.
-Each user, or even each working directory, can have their own
+Each user, or even each workspace, can have their own
implementation of these hooks, and thus a different filtered view of
valid revisions, according to their own preferences and purposes.
@@ -6541,7 +6541,7 @@
writing data to the terminal, or otherwise interfacing with the user.
The system line separator is not used to convert files in the working
copy; use @code{get_linesep_conv} for converting line endings in the
-working copy.
+workspace.
This hook has no default definition. For more information on line
ending conversion, see the section on @ref{Internationalization}.
@@ -6556,9 +6556,9 @@
conventions should be one of the strings @code{CR}, @code{LF}, or
@code{CRLF}.
-When @var{filename} is read from the working copy, it is run through
+When @var{filename} is read from the workspace, it is run through
line ending conversion from the external form to the internal
-form. When @var{filename} is written to the working copy, it is run
+form. When @var{filename} is written to the workspace, it is run
through line ending conversion from the internal form to the external
form. @sc{sha1} values are calculated from the internal form of
@var{filename}. It is your responsibility to decide which line ending
@@ -6577,9 +6577,9 @@
the return value is the name of a character set to use for the
``external'' representation of @var{filename}.
-When @var{filename} is read from the working copy, it is run through
+When @var{filename} is read from the workspace, it is run through
character set conversion from the external form to the internal
-form. When @var{filename} is written to the working copy, it is run
+form. When @var{filename} is written to the workspace, it is run
through character set conversion from the internal form to the
external form. @sc{sha1} values are calculated from the internal
form of @var{filename}. It is your responsibility to decide which
@@ -6601,10 +6601,10 @@
Monotone allows each file in a repository to carry arbitrary @ref{File
Attributes}. Persistent attributes are stored in the @file{.mt-attrs},
-in your working copy and manifest. The hooks in this section allow files
+in your workspace and manifest. The hooks in this section allow files
to be automatically recognised as having certain attributes at the time
they're added, and for custom triggers to be invoked on each file
-according to its attributes when the working copy is changed.
+according to its attributes when the workspace is changed.
@ftable @code
@item attr_functions address@hidden (@var{filename}, @var{value})
@@ -6856,13 +6856,13 @@
@item
Monotone's control files are stored in UTF-8. This includes: revisions
and manifests, both inside the database and when written to the
address@hidden/} directory of the working copy; the @file{MT/options} and
address@hidden/} directory of the workspace; the @file{MT/options} and
@file{MT/work} files; and the @file{.mt-attrs} file. Converting these
files to any other character set will cause monotone to break; do not
do so.
@item
-File path names in the working copy are converted to the locale's
+File path names in the workspace are converted to the locale's
character set (determined via the LANG or CHARSET environment
variables) before monotone interacts with the file system. If you are
accustomed to being able to use file names in your locale's character
@@ -7476,15 +7476,15 @@
@comment TROFF INPUT: .TP
@item @b{diff} @i{[--revision= [--revision=] ] [...]}
-Show diffs between working copy and database.
+Show diffs between workspace and database.
@comment TROFF INPUT: .TP
@item @b{status} @i{[...]}
-Show status of working copy.
+Show status of workspace.
@comment TROFF INPUT: .TP
@item @b{log} @i{[id]}
-Show historical log of revisions, starting from working copy
+Show historical log of revisions, starting from workspace
base revision, or @i{[id]} if given.
@comment TROFF INPUT: .TP
@@ -7528,12 +7528,12 @@
@item @b{list known} @i{[...]}
@itemx @b{ls known} @i{[...]}
List files which are in revision's manifest, or are on the work list of
-the working copy.
+the workspace.
@comment TROFF INPUT: .TP
@item @b{list unknown} @i{[...]}
@itemx @b{ls unknown} @i{[...]}
-List files in working copy, but not in revision's manifest or
+List files in workspace, but not in revision's manifest or
work list.
@comment TROFF INPUT: .TP
@@ -7544,7 +7544,7 @@
@item @b{list missing} @i{[...]}
@itemx @b{ls missing} @i{[...]}
-List files in revision's manifest, but not in working copy.
+List files in revision's manifest, but not in workspace.
@comment TROFF INPUT: .TP
@item @b{fdata} @i{}
@@ -7613,7 +7613,7 @@
@comment TROFF INPUT: .TP
@item @b{add} @i{[--unknown] [...]}
-Add files to working copy. adding a file does not copy it into the
+Add files to workspace. adding a file does not copy it into the
database, merely adds it to the work list. You must @b{commit} your
changes in order to copy added files to the database. The missing
flag causes those files that @command{monotone ls unknown} would
@@ -7621,20 +7621,20 @@
@comment TROFF INPUT: .TP
@item @b{drop} @i{[--missing] [--execute] [...]}
-Drop files from working copy. Files are not deleted from working copy,
+Drop files from workspace. Files are not deleted from workspace,
merely noted as removals in the work list, unless the @option{--execute}
flag is given. If the @option{--missing} flag is given any files that
-monotone is tracking but which are not present in the working copy
+monotone is tracking but which are not present in the workspace
(ie. the output that @command{monotone ls missing} would give) are
dropped.
@comment TROFF INPUT: .TP
@item @b{rename} @i{ }
-Rename files from @i{} to @i{} in working copy.
+Rename files from @i{} to @i{} in workspace.
@comment TROFF INPUT: .TP
@item @b{commit} @i{[--message=log message | --message-file=log message file] [...]}
-Commit working copy to database. Each commit has a changelog message
+Commit workspace to database. Each commit has a changelog message
associated with it. If @option{--message} is provided on the command
line, it is used; if @option{--message-file} is provided, the content of
the named file will be used as a commit message. If the filename is '-'
@@ -7647,7 +7647,7 @@
@comment TROFF INPUT: .TP
@item @b{update} @i{[--revision=revision]}
-Update working copy.
+Update workspace.
@comment TROFF INPUT: .SH DESCRIPTION
@item @b{refresh_inodeprints}
@@ -7734,7 +7734,7 @@
@item @b{--norc}
Do not load Lua hooks from user's @b{~/.monotone/monotonerc} or the
-working copy's @b{MT/monotonerc} file.
+workspace's @b{MT/monotonerc} file.
@comment TROFF INPUT: .TP
@item @address@hidden}
@@ -7796,7 +7796,7 @@
importing history from another version control system.
@item @address@hidden}
-Stop the search for a working copy (containing the @file{MT} directory)
+Stop the search for a workspace (containing the @file{MT} directory)
at the specified root directory rather than at the physical root of the
filesystem.
============================================================
--- paths.cc a88d2a803ce9e069bd8b0b6d5db4d2c2593de689
+++ paths.cc 227025632497d6849fc4946feeded4d7980f7008
@@ -179,10 +179,10 @@
case external:
if (!initial_rel_path.initialized)
{
- // we are not in a working directory; treat this as an internal
+ // we are not in a workspace; treat this as an internal
// path, and set the access_tracker() into a very uninitialised
// state so that we will hit an exception if we do eventually
- // enter a working directory
+ // enter a workspace
initial_rel_path.may_not_initialize();
data = path;
N(is_valid_internal(path) && !in_bookkeeping_dir(path),
@@ -435,11 +435,11 @@
#endif
}
-system_path::system_path(any_path const & other, bool in_true_working_copy)
+system_path::system_path(any_path const & other, bool in_true_workspace)
{
I(!is_absolute_here(other.as_internal()));
system_path wr;
- if (in_true_working_copy)
+ if (in_true_workspace)
wr = working_root.get();
else
wr = working_root.get_but_unused();
@@ -467,11 +467,11 @@
}
///////////////////////////////////////////////////////////////////////////
-// working copy (and path roots) handling
+// workspace (and path root) handling
///////////////////////////////////////////////////////////////////////////
bool
-find_and_go_to_working_copy(system_path const & search_root)
+find_and_go_to_workspace(system_path const & search_root)
{
// unimplemented
fs::path root(search_root.as_external(), fs::native);
@@ -530,11 +530,11 @@
}
void
-go_to_working_copy(system_path const & new_working_copy)
+go_to_workspace(system_path const & new_workspace)
{
- working_root.set(new_working_copy, true);
+ working_root.set(new_workspace, true);
initial_rel_path.set(fs::path(), true);
- change_current_working_dir(new_working_copy);
+ change_current_working_dir(new_workspace);
}
///////////////////////////////////////////////////////////////////////////
@@ -916,7 +916,7 @@
// MT/options
// /work/newdir$ cd ..
// /work$ mv newdir newerdir # better name
- // Oops, now, if we stored the version with ..'s in, this working directory
+ // Oops, now, if we stored the version with ..'s in, this workspace
// is broken.
check_system_normalizes_to("../foo", "/a/foo");
check_system_normalizes_to("foo/..", "/a/b");
============================================================
--- paths.hh f61b1b0f8a6fe9f4b6a55ff1a5513412856cb75c
+++ paths.hh 727b9cfba7c9d150dfd7144d0d38744beb8dda7f
@@ -23,7 +23,7 @@
// always absolute. when constructed from a string, it interprets the
// string as being relative to the directory that monotone was run in.
// (note that this may be different from monotone's current directory, as
-// when run in working copy monotone chdir's to the project root.)
+// when run in workspace monotone chdir's to the project root.)
//
// one can also construct a system_path from one of the below two types
// of paths. this is intelligent, in that it knows that these sorts of
@@ -46,16 +46,16 @@
// file_path_external: use this for strings that come from the user.
// these strings are normalized before being checked, and if there is
// a problem trigger N() invariants rather than I() invariants. if in
-// a working directory, such strings are interpreted as being
+// a workspace, such strings are interpreted as being
// _relative to the user's original directory_.
-// if not in a working copy, strings are treated as referring to some
+// if not in a workspace, strings are treated as referring to some
// database object directly.
// file_path's also provide optimized splitting and joining
// functionality.
//
// -- bookkeeping_path
// this is a path representing something in the MT/ directory of a
-// working copy. it has the same format restrictions as a file_path,
+// workspace. it has the same format restrictions as a file_path,
// except instead of being forbidden to point into the MT directory, it
// is _required_ to point into the MT directory. the one constructor is
// strict, and analogous to file_path_internal. however, the normal way
@@ -169,7 +169,7 @@
// -- are converted to internal syntax (/ rather than \, etc.)
// -- normalized
// -- assumed to be relative to the user's cwd, and munged
- // to become relative to root of the working copy instead
+ // to become relative to root of the workspace instead
// both types of paths:
// -- are confirmed to be normalized and relative
// -- not to be in MT/
@@ -215,17 +215,17 @@
system_path() {};
system_path(system_path const & other) : any_path(other) {};
// the optional argument takes some explanation. this constructor takes a
- // path relative to the working copy root. the question is how to interpret
- // that path -- since it's possible to have multiple working copies over the
+ // path relative to the workspace root. the question is how to interpret
+ // that path -- since it's possible to have multiple workspaces over the
// course of a the program's execution (e.g., if someone runs 'checkout'
- // while already in a working copy). if 'true' is passed (the default),
- // then monotone will trigger an invariant if the working copy changes after
+ // while already in a workspace). if 'true' is passed (the default),
+ // then monotone will trigger an invariant if the workspace changes after
// we have already interpreted the path relative to some other working
// copy. if 'false' is passed, then the path is taken to be relative to
- // whatever the current working copy is, and will continue to reference it
- // even if the working copy later changes.
+ // whatever the current workspace is, and will continue to reference it
+ // even if the workspace later changes.
explicit system_path(any_path const & other,
- bool in_true_working_copy = true);
+ bool in_true_workspace = true);
// this path can contain anything, and it will be absolutified and
// tilde-expanded. it will considered to be relative to the directory
// monotone started in. it should be in utf8.
@@ -238,15 +238,15 @@
void
save_initial_path();
-// returns true if working copy found, in which case cwd has been changed
-// returns false if working copy not found
+// returns true if workspace found, in which case cwd has been changed
+// returns false if workspace not found
bool
-find_and_go_to_working_copy(system_path const & search_root);
+find_and_go_to_workspace(system_path const & search_root);
// this is like change_current_working_dir, but also initializes the various
// root paths that are needed to interpret paths
void
-go_to_working_copy(system_path const & new_working_copy);
+go_to_workspace(system_path const & new_workspace);
typedef std::set path_set;
============================================================
--- platform.hh f0d95c6add214117b2aa25646a9f62f750764a53
+++ platform.hh 0219de39c44ef3898973d9568b5ce26593dbca7c
@@ -34,7 +34,7 @@
// return value of 0 means "unlimited"
unsigned int terminal_width();
-// for "reckless mode" working copy change detection.
+// for "reckless mode" workspace change detection.
// returns 'true' if it has generated a valid inodeprint; returns 'false' if
// there was a problem, in which case we should act as if the inodeprint has
// changed.
============================================================
--- roster.cc 67380c22a3dfef07d49edbc75646a4b0668de5cb
+++ roster.cc e1c0e9fe71f80b5bd457801d3cf4eb3240872c22
@@ -1975,7 +1975,7 @@
}
////////////////////////////////////////////////////////////////////
-// getting rosters from the working copy
+// getting rosters from the workspace
////////////////////////////////////////////////////////////////////
inline static bool
============================================================
--- std_hooks.lua a5e3529e680469a911323f45286466780088f35d
+++ std_hooks.lua 1740ad529749fadac6c115b8373ca26e9f932ad6
@@ -33,7 +33,7 @@
-- attributes are persistent metadata about files (such as execute
-- bit, ACLs, various special flags) which we want to have set and
-- re-set any time the files are modified. the attributes themselves
--- are stored in a file .mt-attrs, in the working copy (and
+-- are stored in a file .mt-attrs, in the workspace (and
-- manifest). each (f,k,v) triple in an attribute file turns into a
-- call to attr_functions[k](f,v) in lua.
============================================================
--- tests/t_add_vs_commit.at 795e4288501968701031a986173a6d3d4bfce367
+++ tests/t_add_vs_commit.at 854fb99182fa82f283d2a26b089e770909461fa5
@@ -1,4 +1,4 @@
-AT_SETUP([add working copy commit in another])
+AT_SETUP([add workspace commit in another])
MONOTONE_SETUP
# This test relies on file-suturing
============================================================
--- tests/t_automate_inventory.at 390524783f3f55102d9d20a3606cff4b09ed9722
+++ tests/t_automate_inventory.at 1a9fcca95a722a81cf5fe49a6dd7025900c4e311
@@ -1,4 +1,4 @@
-AT_SETUP([working copy inventory])
+AT_SETUP([workspace inventory])
MONOTONE_SETUP
AT_DATA(inventory_hooks.lua, [
============================================================
--- tests/t_commit_message_file.at 447a09a7a56815e3298f30a6c84a89882340c029
+++ tests/t_commit_message_file.at ff5ee2bfe41e4807ee909ee5319db3d7eff38173
@@ -23,7 +23,7 @@
AT_CHECK(QGREP('this commit uses the --message-file option' stdout), [])
#--------------------
-#also with a file coming outside the working copy
+#also with a file coming outside the workspace
#--------------------
AT_CHECK(MONOTONE setup --branch=testbranch alt_wrk, [], [ignore], [ignore])
============================================================
--- tests/t_cvsimport.at cdb0a29f99f219dd5c2f4ebb2f3da47003ca10d7
+++ tests/t_cvsimport.at 42e05f340ace04dd4bfdc4e948ab651669f8d2b8
@@ -29,7 +29,7 @@
AT_CHECK(test -e $CVSROOT/CVSROOT)
AT_CHECK(test -e $CVSROOT/CVSROOT/history)
-# check out the working copy and make some commits
+# check out the workspace and make some commits
AT_CHECK(cvs -d $CVSROOT co ., [], [ignore], [ignore])
AT_CHECK(mkdir testdir)
============================================================
--- tests/t_cvsimport_samelog.at ccac785c1ac8421e23723f4cdd9e69ce10be7e93
+++ tests/t_cvsimport_samelog.at 515ea15748990c4be6f61a9a811266b58fb331e7
@@ -29,7 +29,7 @@
AT_CHECK(test -e $CVSROOT/CVSROOT)
AT_CHECK(test -e $CVSROOT/CVSROOT/history)
-# check out the working copy and make some commits
+# check out the workspace and make some commits
AT_CHECK(cvs -d $CVSROOT co ., [], [ignore], [ignore])
AT_CHECK(mkdir testdir)
============================================================
--- tests/t_database_check.at b034de4e58d344e3ac343a04f29bea851aa93717
+++ tests/t_database_check.at 332a5aec62e318573ab12e222b0cd31e56951b97
@@ -58,7 +58,7 @@
AT_CHECK(MONOTONE commit --branch=test --message='to be removed', [], [ignore], [ignore])
REV4=`BASE_REVISION`
AT_CHECK(MONOTONE db execute "delete from revisions where id='$REV4'", [0], [ignore], [ignore])
-# revert to the old working copy state
+# revert to the old workspace state
AT_CHECK(echo $REV3 > MT/revision)
# remove another file too
AT_CHECK(MONOTONE db execute "delete from files where id='$FILE3'", [], [ignore], [ignore])
============================================================
--- tests/t_diff_outside_working_dir.at 68e1ab2a3186b905dc91af7814cb0dc10594bb3f
+++ tests/t_diff_outside_workspace.at 28c8bf8ea6fc2088a754308386f6ab936506dc77
@@ -1,6 +1,6 @@
# -*- Autoconf -*-
-AT_SETUP([diffing a file within revision outside a working dir])
+AT_SETUP([diffing a file within revision outside a workspace])
MONOTONE_SETUP
============================================================
--- tests/t_drop_missing.at 76df22384469606ea77735754609229018a6f6a5
+++ tests/t_drop_missing.at b57855a8b89e7f7c8c7cab3ae9fdf660bc4c0111
@@ -20,7 +20,7 @@
AT_CHECK(rm maude)
AT_CHECK(MONOTONE drop maude, [], [ignore], [stderr])
-AT_CHECK(grep 'adding maude to working copy delete set' stderr, [0], [ignore])
+AT_CHECK(grep 'adding maude to workspace delete set' stderr, [0], [ignore])
AT_CHECK(MONOTONE status, [], [stdout])
AT_CHECK(grep maude stdout, [0], [ignore])
@@ -34,8 +34,8 @@
AT_CHECK(rm places/cemetery)
AT_CHECK(MONOTONE drop --missing, [], [ignore], [stderr])
-AT_CHECK(grep 'adding harold to working copy delete set' stderr, [0], [ignore])
-AT_CHECK(grep 'adding places/cemetery to working copy delete set' stderr, [0], [ignore])
+AT_CHECK(grep 'adding harold to workspace delete set' stderr, [0], [ignore])
+AT_CHECK(grep 'adding places/cemetery to workspace delete set' stderr, [0], [ignore])
AT_CHECK(MONOTONE status, [], [stdout])
AT_CHECK(grep maude stdout, [0], [ignore])
============================================================
--- tests/t_existsonpath.at 4f555bc7a0c0f3d218a445d3fb78cdcf57147345
+++ tests/t_existsonpath.at 984ebe7ce8dbd63cb065fc1fd5f17c16df3c9fb6
@@ -1,9 +1,9 @@
AT_SETUP([lua function existsonpath])
MONOTONE_SETUP
# Need a way to break into the lua interpreter; our strategy is to
# redefine the use_inodeprints function to run our code, and then
-# create a new working copy.
+# create a new workspace.
AT_DATA(test.lua, [function use_inodeprints()
if (existsonpath("ls") == 0) then
============================================================
--- tests/t_lf_crlf.at 8e233d81e10aa6d9bab1d7bb38ba7f183ad151b2
+++ tests/t_lf_crlf.at 19b497fd65b459240b83270df348bab82f09962c
@@ -1,9 +1,9 @@
AT_SETUP([use get_linesep_conv hook])
MONOTONE_SETUP
# This test excercises the common case of wanting to do newline
# character conversion so that win32 users can have native line endings
-# in their working copies.
+# in their workspace.
AT_CHECK(printf "foo\r\n", [], [stdout])
AT_CHECK(mv stdout foo.crlf)
============================================================
--- tests/t_log_outside_working_dir.at 1e6f8f708369425dfb8bf1f06f4b9f283e24de01
+++ tests/t_log_outside_workspace.at 408e3882754be40081c953771285895e36fd2de8
@@ -1,6 +1,6 @@
# -*- Autoconf -*-
-AT_SETUP([logging a file within revision outside a working dir])
+AT_SETUP([logging a file within revision outside a workspace])
MONOTONE_SETUP
============================================================
--- tests/t_ls_known.at 99eb14f8f7144c26b858c836b5fcdc355d0a246d
+++ tests/t_ls_known.at 6c871d99df8c34c37190d281ca538aa5c90e37a4
@@ -1,6 +1,6 @@
# -*- Autoconf -*-
-AT_SETUP([listing working copy manifests])
+AT_SETUP([listing workspace manifests])
MONOTONE_SETUP
============================================================
--- tests/t_rename.at c237939fa3e27409437b44b2117942e07f05779e
+++ tests/t_rename.at b95e23675e65c4c3c9bd2b3490d08ce117b11836
@@ -53,7 +53,7 @@
AT_CHECK(MONOTONE status, [], [ignore], [ignore])
AT_CHECK(mv bar barfoo)
AT_CHECK(MONOTONE rename bar barfoo, [], [ignore], [stderr])
-AT_CHECK(grep 'adding bar -> barfoo to working copy rename set' stderr, [0], [ignore])
+AT_CHECK(grep 'adding bar -> barfoo to workspace rename set' stderr, [0], [ignore])
AT_CHECK(MONOTONE status, [], [ignore], [ignore])
# move file to wrong place before renaming it
@@ -62,7 +62,7 @@
AT_CHECK(MONOTONE status, [], [ignore], [ignore])
AT_CHECK(mv bar barfoofoo)
AT_CHECK(MONOTONE rename bar barfoo, [], [ignore], [stderr])
-AT_CHECK(grep 'adding bar -> barfoo to working copy rename set' stderr, [0], [ignore])
+AT_CHECK(grep 'adding bar -> barfoo to workspace rename set' stderr, [0], [ignore])
AT_CHECK(MONOTONE status, [1], [ignore], [ignore])
AT_CLEANUP
============================================================
--- tests/t_restricted_commands_consistent.at a8a896d3209ec673f8197488d639226d62b18158
+++ tests/t_restricted_commands_consistent.at e11f8aafa55195d6350e35bd53e9fc0e11b0d1d6
@@ -91,7 +91,7 @@
DEPTH_INCLUDED="file1 file2 foo/foo1 foo/foo2"
DEPTH_EXCLUDED="foo/bar/bar1 foo/bar/bar2"
-# setup working copy
+# setup workspace
AT_CHECK(mkdir foo)
AT_CHECK(mkdir foo/bar)
============================================================
--- tests/t_singlecvs.at 3ab763cc4821f58ecc8cea7ff0d1b8f62004c8ad
+++ tests/t_singlecvs.at d98391bad7a3290996b9a4354e173ccd3277b001
@@ -17,7 +17,7 @@
AT_CHECK(test -e $CVSROOT/CVSROOT)
AT_CHECK(test -e $CVSROOT/CVSROOT/history)
-# check out the working copy and make a commit
+# check out the workspace and make a commit
AT_CHECK(cvs -d $CVSROOT co ., [], [ignore], [ignore])
AT_CHECK(mkdir testdir)
============================================================
--- tests/t_undo_update.at 85012f2040dd0f9f6aa13b3c748bf38ea9c10fe7
+++ tests/t_undo_update.at 23512408a71b29946fbeb5b1d5058c6a5f9abd87
@@ -1,9 +1,9 @@
AT_SETUP([(todo) undo_update command])
# This test is a bug report.
AT_XFAIL_IF(true)
-# "update" is the only command that modifies the working copy, i.e.,
+# "update" is the only command that modifies the workspace, i.e.,
# it is the only command that may destroy data that cannot be easily
# recovered from the database. So it should be undo-able.
#
@@ -12,8 +12,8 @@
# them somewhere under MT/. The only tricky part is making sure we
# can undo tree rearrangements.
#
-# For bonus points, use this to implement "working copy rollback" --
-# right now, we can't modify the working copy atomically. But if we
+# For bonus points, use this to implement "workspace rollback" --
+# right now, we can't modify the workspace atomically. But if we
# always saved this information before touching any files, then we
# could also save a marker file when we start munging the filesystem,
# that we delete when finished. When monotone starts up, it can check
@@ -29,7 +29,7 @@
# It'd also be nice if there was a "redo_update" to un-undo an update,
# I suppose...
-# Are there any other operations that mutate the working copy? They
+# Are there any other operations that mutate the workspace? They
# should all be reversible somehow...
AT_CHECK(false)
============================================================
--- tests/t_update_to_revision.at b6f804cced8a6863a91e4fef319b8f427762001e
+++ tests/t_update_to_revision.at 5c67e05438436f0e76bbb4b535481cb4b0f5a27d
@@ -71,7 +71,7 @@
AT_CHECK(MONOTONE update --revision=$LEFT_LEAF_R_SHA, [], [ignore], [ignore])
AT_CHECK(cmp testfile left-leaf, [], [ignore])
-# Test that working copy changes are kept while going backward.
+# Test that workspace changes are kept while going backward.
AT_CHECK(cp modified-left-leaf testfile)
AT_CHECK(MONOTONE update --revision=$ROOT_R_SHA, [], [ignore], [ignore])
AT_CHECK(cmp testfile modified-root, [], [ignore])
============================================================
--- tests/t_update_with_pending_add.at 3d046ef7f426d6e5d89b0423c72242fde52142e4
+++ tests/t_update_with_pending_add.at af1ac1b21a52bade76fa8fa92cae2c5be1a18321
@@ -24,7 +24,7 @@
AT_CHECK(cd codir && MONOTONE add file2, [], [ignore], [ignore])
AT_CHECK(cd codir && MONOTONE update, [], [ignore], [ignore])
-# make sure there are no changes in the working copy
+# make sure there are no changes in the workspace
AT_CHECK(test ! -e codir/MT/work, [], [ignore], [ignore])
AT_CHECK(cd codir && MONOTONE diff, [], [stdout], [ignore])
============================================================
--- tests/t_update_with_pending_drop.at af78561aa074371619cdcdd49ec78084dd0ecf0d
+++ tests/t_update_with_pending_drop.at 04407e4305991ff2358e52325d584674e8f0fcd2
@@ -23,7 +23,7 @@
AT_CHECK(cd codir && MONOTONE automate get_revision $REV, [], [ignore], [ignore])
-# make sure there are no changes in the working copy
+# make sure there are no changes in the workspace
AT_CHECK(test ! -e codir/MT/work, [], [ignore], [ignore])
AT_CHECK(cd codir && MONOTONE diff, [], [stdout], [ignore])
============================================================
--- tests/t_update_with_pending_rename.at c77760a120745388dc4fda95d8d617b7c052ce42
+++ tests/t_update_with_pending_rename.at 2577008031f11dbdeaceeda708d4238b5b52c641
@@ -24,7 +24,7 @@
AT_CHECK(cd codir && MONOTONE automate get_revision $REV, [], [ignore], [ignore])
-# make sure there are no changes in the working copy
+# make sure there are no changes in the workspace
AT_CHECK(test ! -e codir/MT/work, [], [ignore], [ignore])
AT_CHECK(cd codir && MONOTONE diff, [], [stdout], [ignore])
============================================================
--- testsuite.at c4a1c8a8aa70c27d11caeb9c70ba713680109fee
+++ testsuite.at 9e39ba6a09e3b23919675a2ae8adf1275eac5e08
@@ -743,8 +743,8 @@
m4_include(tests/t_rename_diff_names.at)
m4_include(tests/t_key_management_without_db.at)
m4_include(tests/t_automate_keys.at)
-m4_include(tests/t_diff_outside_working_dir.at)
-m4_include(tests/t_log_outside_working_dir.at)
+m4_include(tests/t_diff_outside_workspace.at)
+m4_include(tests/t_log_outside_workspace.at)
m4_include(tests/t_add_inside_MT.at)
m4_include(tests/t_annotate_renames.at)
m4_include(tests/t_config_confdir.at)
============================================================
--- work.cc f0b8375e1b0bfbaf32770b41ece3015e2a34cb66
+++ work.cc 974c1d8a5295fd7317898e60abc636fdcc82ba65
@@ -20,7 +20,7 @@
#include "vocab.hh"
#include "work.hh"
-// working copy / book-keeping file code
+// workspace / book-keeping file code
using namespace std;
@@ -122,11 +122,11 @@
path.split(sp);
if (ros.has_node(sp))
{
- P(F("skipping %s, already accounted for in working copy\n") % path);
+ P(F("skipping %s, already accounted for in workspace\n") % path);
return;
}
- P(F("adding %s to working copy add set\n") % path);
+ P(F("adding %s to workspace add set\n") % path);
split_path dirname, prefix;
path_component basename;
@@ -209,7 +209,7 @@
N(d->children.empty(),
F("cannot remove %s/, it is not empty") % name);
}
- P(F("adding %s to working copy delete set\n") % name);
+ P(F("adding %s to workspace delete set\n") % name);
new_roster.drop_detached_node(new_roster.detach_node(*i));
if (app.execute && path_exists(name))
delete_file_or_dir_shallow(name);
@@ -305,7 +305,7 @@
{
node_id nid = new_roster.detach_node(i->first);
new_roster.attach_node(nid, i->second);
- P(F("adding %s -> %s to working copy rename set")
+ P(F("adding %s -> %s to workspace rename set")
% file_path(i->first)
% file_path(i->second));
}
@@ -330,11 +330,11 @@
}
else if (!have_src && !have_dst)
{
- W(F("%s doesn't exist in working copy, skipping") % s);
+ W(F("%s doesn't exist in workspace, skipping") % s);
}
else if (have_src && have_dst)
{
- W(F("destination %s already exists in working copy, skipping") % d);
+ W(F("destination %s already exists in workspace, skipping") % d);
}
else
{
@@ -418,8 +418,8 @@
get_revision_path(c_path);
require_path_is_file(c_path,
- F("working copy is corrupt: %s does not exist") % c_path,
- F("working copy is corrupt: %s is a directory") % c_path);
+ F("workspace is corrupt: %s does not exist") % c_path,
+ F("workspace is corrupt: %s is a directory") % c_path);
data c_data;
L(FL("loading revision id from %s\n") % c_path);
@@ -429,7 +429,7 @@
}
catch(std::exception & e)
{
- N(false, F("Problem with working directory: %s is unreadable") % c_path);
+ N(false, F("Problem with workspace: %s is unreadable") % c_path);
}
c = revision_id(remove_ws(c_data()));
}
@@ -796,7 +796,7 @@
bookkeeping_path src_pth = path_for_nid(nid);
file_path dst_pth(dst);
- // Possibly just write data out into the working copy, if we're doing
+ // Possibly just write data out into the workspace, if we're doing
// a file-create (not a dir-create or file/dir rename).
if (!file_exists(src_pth))
{
============================================================
--- work.hh 8c9dc3dba09d6c20d9afb4c9f7c1e11e28e489bb
+++ work.hh 723c827976adf80b589df8c0e2629ed7fafb907e
@@ -17,12 +17,12 @@
#include "vocab.hh"
//
-// this file defines structures to deal with the "working copy" of a tree
+// this file defines structures to deal with the "workspace" of a tree
//
//
-// working copy book-keeping files are stored in a directory called MT, off
-// the root of the working copy source tree (analogous to the CVS or .svn
+// workspace book-keeping files are stored in a directory called MT, off
+// the root of the workspace source tree (analogous to the CVS or .svn
// directories). there is no hierarchy of MT directories; only one exists,
// and it is always at the root. it contains the following files:
//
@@ -34,7 +34,7 @@
// MT/inodeprints -- file fingerprint cache, presence turns on "reckless"
// mode
//
-// as work proceeds, the files in the working directory either change their
+// as work proceeds, the files in the workspace either change their
// sha1 fingerprints from those listed in the revision's manifest, or else are
// added or deleted or renamed (and the paths of those changes recorded in
// 'MT/work').
@@ -42,7 +42,7 @@
// when it comes time to commit, the cset in MT/work (which can have no
// deltas) is applied to the base roster, then a new roster is built by
// analyzing the content of every file in the roster, as it appears in the
-// working copy. a final cset is calculated which contains the requisite
+// workspace. a final cset is calculated which contains the requisite
// deltas, and placed in a rev, which is written to the db.
//
// MT/inodes, if present, can be used to speed up this last step.
@@ -129,7 +129,7 @@
// the "options map" is another administrative file, stored in
// MT/options. it keeps a list of name/value pairs which are considered
-// "persistent options", associated with a particular the working copy and
+// "persistent options", associated with a particular the workspace and
// implied unless overridden on the command line. the main ones are
// --branch and --db, although some others may follow in the future.