# # # 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.