# # # add_file "wiki/UnixAttribsAndSymlinks.mdwn" # content [9eceb1dcc95b06abd77a12c637692402b5f43776] # # patch "wiki/Feature/AccessControl.mdwn" # from [fd35de82b389278ed8efaf000258678216bcb5c4] # to [60bba62037ca739be1dbd219c2fd014ba512ed81] # # patch "wiki/Feature/AtomicCommit.mdwn" # from [62cbb1633b28a91f02d70fc6d57d88d4f88053f1] # to [f8dfc39926083c0a8d3374ad4d1a54c4696ee30f] # # patch "wiki/Feature/BuildIntegration.mdwn" # from [34c48ffeae8871727704d52876d5f142ac3297f1] # to [cc69d952589308373ce8b175c57b57acf185aa23] # # patch "wiki/Feature/CVSExport.mdwn" # from [0ee0c4d5bd1c11d140fdd94ac78f2bc8af763d83] # to [48a6030565a9ef1fd4f37ed412aac37b9af97e72] # # patch "wiki/Feature/CVSImport.mdwn" # from [1ebd307f9eafad6cd3d1bf1f81bb32f033a60e24] # to [65ccb6999748060e36ed36c807cf1e853e3e64e1] # # patch "wiki/Feature/CommitMail.mdwn" # from [41391462d99ab161d25619812ec51a0dc5651ce6] # to [92dad24fad74a29e01d29027c237f8c5b2a830fe] # # patch "wiki/Feature/CompactRepository.mdwn" # from [ae47674eb6960d3b72dbdff490e580ea202630c1] # to [91694a723f0260e96a44b5cc73cea0f393505a6d] # # patch "wiki/Feature/EmbeddedIDs.mdwn" # from [ef1123bdbf5da65e9d178ada663d70c0b84b0519] # to [df4b6cc1d6a05e859807c4048a8ddd7f7a3c9b2e] # # patch "wiki/Feature/Fast.mdwn" # from [f5ca9c5143b32c6816091d0be9bf1ebf75cce80c] # to [f5c41dfdcff567c6064997005578212b14064245] # # patch "wiki/Feature/LightweightBranches.mdwn" # from [113eaacc5fdd34c6330a8b4aa2dec2280ccc1d99] # to [525b7b92e477d7bdd5ed4d5d8d680a478cd56e95] # # patch "wiki/Feature/LogReview.mdwn" # from [912ff658418d96d163c6a900731a368318b014d9] # to [ec30798076c100d6da5820c292387dd9de3a35e4] # # patch "wiki/Feature/LogTemplates.mdwn" # from [ac6cf94eb237a6feba601581e4a5240122907f6c] # to [e73c9eb141680876ff3f4fb076fbed40a30c06ac] # # patch "wiki/Feature/MIMEtypes.mdwn" # from [2689db6ba3008991214115f9644d5873d476a864] # to [6219836853794712e19ca05dc46f635c81ded7bd] # # patch "wiki/Feature/Merging.mdwn" # from [64d10b953c8de7c089998d8adda7794d7790fa0a] # to [69beef33d039074a1101789869dd9e832fc0a61d] # # patch "wiki/Feature/Mirroring.mdwn" # from [1f8f6f3389430038e71ea158bfd90288e6311520] # to [cb8ee0084b9413a090d846f3f62f52d912af6221] # # patch "wiki/Feature/NetworkSecurity.mdwn" # from [594d7d68bf4ce54ccf7172a794ea5a052b833458] # to [7f11427d6f6396de5bdbea0d2e7282e64bb22055] # # patch "wiki/Feature/Obliterate.mdwn" # from [132fb91bd79ee9985b57d55ab381d4f74e58cfac] # to [086944c440b38fa13960469f71c3534f30b7b457] # # patch "wiki/Feature/Offline.mdwn" # from [a6d9631c23fcc0c19b2cb202957e145c90544ddc] # to [cdd5986b2b5bded106adcb21e776b9dadcf9de5f] # # patch "wiki/Feature/Portable.mdwn" # from [e1d50d7cafdc0e0f89f0c78bce3629202afe47a9] # to [9dbe7056d6aef5901a5dfc118cd0e45f8c7d6912] # # patch "wiki/Feature/Rename.mdwn" # from [1dfa84a25d2b4e378a8feab86291bcaaf0b9d37b] # to [f81ac92e084d27793772902720cf20e534dd97af] # # patch "wiki/Feature/RobustRepository.mdwn" # from [023e466445479a3ad974398c8605a12ff49e64a7] # to [1c63ac339046b3831c3bcf49f7e3eb9a3ae957a2] # # patch "wiki/Feature/SignedRevisions.mdwn" # from [5e0760f7279533c01d8820e7eabc3ad215c7ca65] # to [a25d0a0312e86cc16ead3e1a88e8a23e20b537f0] # # patch "wiki/Feature/Symlinks.mdwn" # from [180df0600f90c1e0e095636fc8a08a6f42137e15] # to [6def6a91992560aead175b4134fec30b34a3c606] # # patch "wiki/Feature/Template.mdwn" # from [11a1dc401fbfe8b5e08722ecb19b895e352276a7] # to [84c781591b290cfa861e583cb507bfb8bb4a995e] # # patch "wiki/Feature/VendorBranches.mdwn" # from [633542b06c347681cd56e9596837b82c85400887] # to [c57151610ef76c11448728d29ec4fced52ff7e99] # # patch "wiki/Feature/WebInterface.mdwn" # from [9294b668202df884f61bd3b643b20c9fad27bfdf] # to [f925ce7ae0e820861f9a23943bade74439708307] # # patch "wiki/VendorBranchPattern.mdwn" # from [5df1301f79eb01e24f3501dd2fdcab509eea7b08] # to [f51792f8e19e6f916e9a38f81e068894253f4c03] # ============================================================ --- wiki/UnixAttribsAndSymlinks.mdwn 9eceb1dcc95b06abd77a12c637692402b5f43776 +++ wiki/UnixAttribsAndSymlinks.mdwn 9eceb1dcc95b06abd77a12c637692402b5f43776 @@ -0,0 +1,481 @@ +[[tag migration-wip]] + + +# Tracking Unix Attributes and Symlinks + +## In Progress + +I currently have a branch of monotone-0.29 (net.venge.monotone.cshore.attr-scan) which adds unix user, permission, and symlink tracking. It will eventually hit mainline. In the meantime, you may want to try the following: + +## Workaround + +The following scripts and monotonerc are designed to make it easy to keep track of owner, group, file permissions mode, and the target of symlinks (and the fact that a given file/directory is really a symlink). Unfortunately the commands that check and update attributes are rather slow because monotone's attr get/set commands are painfully slow. + +It should be noted that mtn-dosh is *insecure*. If a shell metacharacters are used in the temporary filename bad things could happen. + +## Core + +### monotonerc + + function getdbgval() + return 0 + end + + function tmpname() + local tmpname = '/tmp/mtn.tmp.' + local getrand + local geterrstr + local randhnd, errstr = io.open('/dev/urandom') + if (randhnd) then + getrand, geterrstr = randhnd:read(8) + if (getrand) then + math.randomseed(string.byte(getrand, 1, 8)) + else + print(geterrstr) + math.randomseed(os.time()) + end + randhnd:close() + for digitnum = 1,10 do + tmpname = tmpname .. string.char(math.random(string.byte('a'),string.byte('z'))) + end + else + print(errstr) + tmpname = tmpname .. 'XXXXXXXXXX' + end + if (getdbgval() > 2) then print("Temp file is: " .. tmpname) end + return tmpname + end + + function argstr(...) + local argstr = "" + for i,v in ipairs(arg) do + if (argstr ~= "") then + argstr = argstr .. ' ' + end + argstr = argstr .. tostring(v) + end + if (getdbgval() > 3) then print("Argument string is: " .. argstr) end + return argstr + end + + function execout(command, ...) + local out = nil + local exec_retval + local tmpfile = tmpname() + local outhnd + local errstr + local out + exec_retval = execute('mtn-dosh', tmpfile, command, unpack(arg)) + if (exec_retval == 0) then + outhnd, errstr = io.open(tmpfile) + if (outhnd) then + out, errstr = outhnd:read() + if (out == nil) then + if (getdbgval() > 1) then + print("Error reading " .. tmpfile .. ": " .. errstr) + end + end + outhnd:close() + os.remove(tmpfile) + else + print("Error opening " .. tmpfile .. ": " .. errstr) + os.remove(tmpfile) + end + else + print('Error executing ' .. argstr(command, unpack(arg)) .. ' > ' .. tmpfile .. ': ' .. tostring(exec_retval)) + os.remove(tmpfile) + end + if (getdbgval() > 1) then + if (out ~= nil) then + print('execout; got ' .. out) + else + print('no output') + end + end + return out + end + + function get_defperms(filetype, is_executable) + local defperms + local perms = execout('umask') + if (perms) then + if ((filetype == "regular file") or (filetype == "regular empty file")) then + if (is_executable) then + defperms = 777 - tonumber(string.sub(perms, 2)) + else + defperms = 666 - tonumber(string.sub(perms, 2)) + end + elseif (filetype == "directory") then + defperms = 777 - tonumber(string.sub(perms, 2)) + else + if (getdbgval() > 2) then + print("Not a regular file or directory, is: " .. filetype) + end + defperms = nil + end + else + defperms = nil + end + if (defperms) then + defpermsstr = string.format("%03d", defperms) + end + if ((getdbgval() > 2) and defpermsstr) then + print("defperms = " .. defpermsstr) + end + return defpermsstr + end + + function get_defuser() + defuser = execout('id', '-u') + if ((getdbgval() > 2) and defuser) then + print("defuser = " .. defuser) + end + return defuser + end + + function get_defgroup() + defgroup = execout('id', '-g') + if ((getdbgval() > 2) and defgroup) then + print("defgroup = " .. defgroup) + end + return defgroup + end + + function has_perms(filename) + local defperms + local perms = execout('stat', '-c', '%a', filename) + local permnum + local retperm = nil + local filetype + + if (perms) then + filetype = execout('stat', '-c', '%F', filename) + if (filetype) then + defperms = get_defperms(filetype, is_executable(filename)) + if (defperms ~= nil) then + permnum = tonumber(perms) + if (permnum ~= tonumber(defperms)) then + retperm = string.format('%03d', permnum) + end + end + end + end + if ((getdbgval() > 2) and retperm) then + print("perms = " .. retperm) + end + return retperm + end + + function has_user(filename) + local user = execout('stat', '-c', '%u', filename) + local defuser = get_defuser() + local retuser = nil + if (user) then + if (defuser) then + if (user ~= defuser) then + retuser = user + end + end + end + if ((getdbgval() > 2) and retuser) then + print("user = " .. retuser) + end + return retuser + end + + function is_symlink(filename) + local filetype = execout('stat', '-c', '%F', filename) + local link_target + local retlink = nil + if (filetype == "symbolic link") then + link_target = execout('readlink', filename) + if (link_target) then + if (link_target ~= "" ) then + retlink = link_target + end + end + end + if ((getdbgval() > 2) and retlink) then + print("linktarget = " .. retlink) + end + return retlink + end + + function has_group(filename) + local group = execout('stat', '-c', '%g', filename) + local defgroup = get_defgroup() + local retgroup = nil + if (group) then + if (defgroup) then + if (group ~= defgroup) then + retgroup = group + end + end + end + if ((getdbgval() > 2) and retgroup) then + print("group = " .. retgroup) + end + return retgroup + end + + attr_init_functions["perms"] = function(filename) + return has_perms(filename) + end + + attr_init_functions["user"] = function(filename) + return has_user(filename) + end + + attr_init_functions["group"] = function(filename) + return has_group(filename) + end + + attr_init_functions["symlink"] = function(filename) + return is_symlink(filename) + end + + attr_functions["perms"] = function(filename, value) + execute("/bin/chmod", value, filename) + end + + attr_functions["user"] = function(filename, value) + execute("/bin/chown", value, filename) + end + + attr_functions["group"] = function(filename, value) + execute("/bin/chgrp", value, filename) + end + + attr_functions["symlink"] = function(filename, value) + execute("/bin/mv", filename, filename .. ".old") + if (execute("/bin/ln", "-s", value, filename) == 0) then + os.remove(filename .. ".old") + else + execute("/bin/cp -a", filename .. ".old", filename) + end + end + +### mtn-dosh + +Execute the specified shell command, redirecting output to the file named by the first parameter + +It should be noted that mtn-dosh is *insecure*. If a shell metacharacters are used in the temporary filename bad things could happen. + + #!/bin/sh + TMPFILE=$1 + shift + $1 $2 $3 $4 $5 $6 $7 $8 $9 > $TMPFILE + +## NOTE + +At this point the following scripts don't work because the mtn attr commands reset the attributes of the files on the filesystem to what's recorded in the monotone workspace before performing the mtn attr set command. + +### mtn-attr-update + +This script does the determines the file's attributes and adds or updates them in monotone. In the interests of performance, only attributes that differ from the expected norm (666-umask for non-exe, 777-umask for exe and dirs, owner:group = current user and group) are stored. + + #!/bin/sh + PREFIX=/usr/bin + OLDBIN=$PREFIX/monotone + NEWBIN=$PREFIX/mtn + + dirlist=$@ + + # Figure out default permissions for regular files + fmask=$(expr 666 - $(expr substr $(umask) 2 3)) + + # Figure out default permissions for executables + emask=$(expr 777 - $(expr substr $(umask) 2 3)) + + # Figure out default permissions for directories + dmask=$(expr 777 - $(expr substr $(umask) 2 3)) + + # Default user and group + duser=$(id -u) + dgroup=$(id -g) + + echo -n "Default file:exe:dir:user:group = " + echo "$fmask:$emask:$dmask:$duser:$dgroup" + + #if [ ! -d "MT" ] && [ ! -d "_MTN" ] ; then + # echo "Error: not in a monotone working directory" + # exit 1 + #fi + + if [ -x $NEWBIN ]; then + ver="0.26+" + BIN=$NEWBIN + elif [ -x $OLDBIN ]; then + ver="0.25-" + BIN=$OLDBIN + else + echo "Can't find monotone in $PREFIX" + exit 2 + fi + + + checkperms () { + perms=$(stat -c '%a' $1) + if [ "$2" = "normal" ]; then + filetype=$(stat --format='%F' $1) + if [ "$filetype" = "regular file" ] || [ "$filetype" = "regular empty file" ]; then + if [ "$perms" != "$fmask" ]; then + if [ "$perms" = "$emask" ]; then + if [ "$ver" = "0.25-" ]; then + $BIN attr set "$1" executable true + INCLUDEFILE=true + fi + else + $BIN attr set "$1" perms "$perms" + INCLUDEFILE=true + fi + fi + elif [ "$filetype" = "directory" ]; then + if [ "$perms" != "$dmask" ]; then + $BIN attr set "$1" perms "$perms" + INCLUDEFILE=true + fi + fi + elif [ "$perms" != "$2" ]; then + $BIN attr set "$1" perms "$perms" + INCLUDEFILE=true + fi + } + + checkuser () { + owner=$(stat -c '%u' $1) + if [ "$owner" != "$2" ]; then + if [ "$owner" = "$duser" ]; then + $BIN attr drop "$1" owner + INCLUDEFILE=true + else + $BIN attr set "$1" owner "$owner" + INCLUDEFILE=true + fi + fi + } + + checkgroup () { + group=$(stat -c '%g' $1) + if [ "$group" != "$2" ]; then + if [ "$group" = "$dgroup" ]; then + $BIN attr drop "$1" owner + INCLUDEFILE=true + else + $BIN attr set "$1" group "$group" + INCLUDEFILE=true + fi + fi + } + + checksymlink () { + filetype=$(stat --format='%F' $1) + if [ "$2" = "normal" ]; then + if [ "$filetype" = "symbolic link" ]; then + ltarget=$(lname=$(stat -c '%N' $1 | cut -f3 -d\ ) ; echo $(expr substr "$lname" 2 $(expr $(echo $lname | wc | tr -s \ | cut -f4 -d\ ) - 3 ) ) ) + $BIN attr set "$1" symlink "$ltarget" + INCLUDEFILE=true + fi + elif [ "$filetype" != "symbolic link" ]; then + $BIN attr drop "$1" symlink + else + ltarget=$(lname=$(stat -c '%N' $1 | cut -f3 -d\ ) ; echo $(expr substr "$lname" 2 $(expr $(echo $lname | wc | tr -s \ | cut -f4 -d\ ) - 3 ) ) ) + if [ "$ltarget" != "$2" ]; then + $BIN attr set "$1" symlink "$ltarget" + INCLUDEFILE=true + fi + fi + } + + if [ "'$@'" != "''" ]; then + echo "Checking for new or changed non-standard attributes for $@" + else + echo "Checking known files for new or changed non-standard attributes" + fi + + filelist=$($BIN list known $@) + + IFS=$'\n' + + for file in $filelist; do + INCLUDEFILE=false + echo -n "Getting recorded attributes for $file ... " + recattr=$($BIN attr get $file) + if [ "$recattr" = "No attributes for '$file'" ]; then + echo "No attributes recorded." + echo -n "Examining attributes of $file ... " + checkperms $file normal + checkuser $file $duser + checkgroup $file $dgroup + checksymlink $file normal + if [ "$INCLUDEFILE" = "true" ]; then + echo "has changed; recorded." + else + echo "unchanged." + fi + else + echo "has attributes; rechecking." + echo -n "Examining attributes of $file ... " + IFS=$'\n' + for attribute in $recattr ; do + hasperms=0 + hasuser=0 + hasgroup=0 + hassymlink=0 + duple=$(echo $attribute | cut -f3 -d\ ) + attrname=$(echo $duple | cut -f1 -d'=' ) + attrval=$(echo $duple | cut -f2 -d'=' ) + case $attrname in + perms) + checkperms $file $attrval + hasperms=1 + ;; + user) + checkuser $file $attrval + hasuser=1 + ;; + group) + checkgroup $file $attrval + hasgroup=1 + ;; + symlink) + checksymlink $file $attrval + hassymlink=1 + ;; + esac + if [ "$hasperms" = "0" ]; then + checkperms $file normal + fi + if [ "$hasuser" = "0" ]; then + checkuser $file $duser + fi + if [ "$hasgroup" = "0" ]; then + checkgroup $file $dgroup + fi + if [ "$hassymlink" = "0" ]; then + checksymlink $file normal + fi + done + if [ "$INCLUDEFILE" = "true" ]; then + echo "has changed; recorded." + else + echo "unchanged." + fi + fi + done + +## Convenience Scripts + +### mtn-commit + +Rechecks all monotone managed files in the current workspace to see if their attributes have changed, and if so, records the new state. + + #!/bin/sh + PREFIX=/usr/bin + OLDBIN=$PREFIX/monotone + NEWBIN=$PREFIX/mtn + + mtn-attr-update $@ + + $BIN mtn commit $@ + ============================================================ --- wiki/Feature/AccessControl.mdwn fd35de82b389278ed8efaf000258678216bcb5c4 +++ wiki/Feature/AccessControl.mdwn 60bba62037ca739be1dbd219c2fd014ba512ed81 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -25,8 +25,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: * [[TrustFoundations]] and [[UsingCerts]] - * [Trust Evaluation Hooks](http://venge.net/monotone/monotone.html#Hooks) - * [Netsync Permission Hooks](http://venge.net/monotone/monotone.html#Hooks) + * [Trust Evaluation Hooks](http://monotone.ca/monotone.html#Hooks) + * [Netsync Permission Hooks](http://monotone.ca/monotone.html#Hooks) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/AtomicCommit.mdwn 62cbb1633b28a91f02d70fc6d57d88d4f88053f1 +++ wiki/Feature/AtomicCommit.mdwn f8dfc39926083c0a8d3374ad4d1a54c4696ee30f @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -12,17 +12,17 @@ In addition, you can `commit` at any tim In addition, you can `commit` at any time to record the current state of your workspace safely. Monotone supports (and encourages) multiple *heads*. You don't have to worry about whether your workspace or repository are up to date with respect to other developers' changes, and you don't have to be interrupted by a need to merge your work with other changes before you can commit. Merging happens as a separate step, when you are ready, and you can always go back to the starting point you just committed if the merge turns out to be difficult. -Commits are atomic both in the VCS sense of a single revision across the entire file tree, as above, and also in the database sense: see [[FeatureRobustRepository]]. +Commits are atomic both in the VCS sense of a single revision across the entire file tree, as above, and also in the database sense: see [[Feature/RobustRepository]]. # Example Usage - $ mtn commit + $ mtn commit # Further Reference Manual and Tutorial Sections: - * [Dealing with a Fork](http://venge.net/monotone/monotone.html#Dealing-with-a-Fork) + * [Dealing with a Fork](http://monotone.ca/monotone.html#Dealing-with-a-Fork) * [[CommitEarlyCommitOften]] Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/BuildIntegration.mdwn 34c48ffeae8871727704d52876d5f142ac3297f1 +++ wiki/Feature/BuildIntegration.mdwn cc69d952589308373ce8b175c57b57acf185aa23 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -17,7 +17,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Quality Assurance](http://venge.net/monotone/monotone.html#Quality-Assurance) + * [Quality Assurance](http://monotone.ca/monotone.html#Quality-Assurance) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/CVSExport.mdwn 0ee0c4d5bd1c11d140fdd94ac78f2bc8af763d83 +++ wiki/Feature/CVSExport.mdwn 48a6030565a9ef1fd4f37ed412aac37b9af97e72 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,9 +8,9 @@ Put revisions committed to monotone back # Not (yet) Supported -This is not yet supported in mainline monotone, but there is experimental code on a branch which does this (see [[BranchStatuses]]). +This is not yet supported in mainline monotone, but there is experimental code on a branch which does this (see [[BranchStatuses]]). -Allowing developers to use ["[[MonotoneAndCVS]]"] together in several different ways is an explicit goal of this effort, but it is complicated by the well-known limitations of CVS. In particular, accurately representing the DAG-structure of monotone commits in a linear CVS history presents special challenges. +Allowing developers to use [[MonotoneAndCVS]] together in several different ways is an explicit goal of this effort, but it is complicated by the well-known limitations of CVS. In particular, accurately representing the DAG-structure of monotone commits in a linear CVS history presents special challenges. It is an explicit goal of this development effort to eventually support replication of this kind with multiple different repositories, whether CVS or other VCS tools, including relaying changes between them via monotone. That ambitious goal is still some way off, however. ============================================================ --- wiki/Feature/CVSImport.mdwn 1ebd307f9eafad6cd3d1bf1f81bb32f033a60e24 +++ wiki/Feature/CVSImport.mdwn 65ccb6999748060e36ed36c807cf1e853e3e64e1 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,9 +8,9 @@ The ability to import past project histo # Partially Supported -monotone can import cvs history, including collecting together changes in multiple files into synthesised change sets. The `cvs_import` command provides this feature; this is just one of several ways of working with ["[[MonotoneAndCVS]]"]. +monotone can import cvs history, including collecting together changes in multiple files into synthesised change sets. The `cvs_import` command provides this feature; this is just one of several ways of working with [[MonotoneAndCVS]]. -The primary limitation is that CVS branches are presently not attached to the revisions they branched off from: each is an independent linear history. Work is underway to resolve this limitation. +The primary limitation is that CVS branches are presently not attached to the revisions they branched off from: each is an independent linear history. Work is underway to resolve this limitation. # Example Usage @@ -24,7 +24,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Importing from CVS](http://venge.net/monotone/monotone.html#Importing-from-CVS) + * [Importing from CVS](http://monotone.ca/monotone.html#Importing-from-CVS) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/CommitMail.mdwn 41391462d99ab161d25619812ec51a0dc5651ce6 +++ wiki/Feature/CommitMail.mdwn 92dad24fad74a29e01d29027c237f8c5b2a830fe @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -16,7 +16,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Event Notification Hooks](http://venge.net/monotone/monotone.html#Hooks) + * [Event Notification Hooks](http://monotone.ca/monotone.html#Hooks) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/CompactRepository.mdwn ae47674eb6960d3b72dbdff490e580ea202630c1 +++ wiki/Feature/CompactRepository.mdwn 91694a723f0260e96a44b5cc73cea0f393505a6d @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -16,27 +16,13 @@ The database format is machine- and endi The database format is machine- and endian-independant, and so databases can be quickly copied between machines where necessary or useful, including as a potential communication channel. History can be transferred or recovered from a copy of a db file on a CD or DVD, as one example. -See also: [[FeatureRobustRepository]] +See also: [[Feature/RobustRepository]] -## = Example Usage = -## -## come up with a better example -## -## To check out multiple workspaces -## -## {{{ -## $ mtn -d monotone.mtn db init -## $ mtn -d monotone.mtn pull venge.net '*' -## $ mtn -d monotone.mtn co -b net.venge.monotone -## $ mtn -d monotone.mtn co -b net.venge.monotone.experiment.foo -## }}} - # Further Reference - Manual and Tutorial Sections: - * [Database Commands](http://venge.net/monotone/monotone.html#Database) + * [Database Commands](http://monotone.ca/monotone.html#Database) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/EmbeddedIDs.mdwn ef1123bdbf5da65e9d178ada663d70c0b84b0519 +++ wiki/Feature/EmbeddedIDs.mdwn df4b6cc1d6a05e859807c4048a8ddd7f7a3c9b2e @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -10,7 +10,7 @@ Monotone does not directly support autom Monotone does not directly support automatic expansion of version strings or other keywords inside file content. Because the SHA-1 hashes of file content are crucial, and because these kinds of flags have proved difficult and confusing in some other systems, implementation of this feature has been avoided up to now -- mostly for lack of a compelling use case. It is certainly possible to add. -Some of the cases where this kind of feature is used in other systems are better addressed by other mechanisms in monotone; in particular it is considered better practice to use the overall revision of the tree rather than a per-file identifier. Monotone uses this for its own embedded version in the executable, accessed via ``mtn --full-version``. Because monotone supports distributed, offline operation, there is also less need for embedded identifiers to determine a file's revision status. Finally, a file's SHA-1 hash **is** its identifier, so unchanged files can be identified in this manner. +Some of the cases where this kind of feature is used in other systems are better addressed by other mechanisms in monotone; in particular it is considered better practice to use the overall revision of the tree rather than a per-file identifier. Monotone uses this for its own embedded version in the executable, accessed via ``mtn version --full``. Because monotone supports distributed, offline operation, there is also less need for embedded identifiers to determine a file's revision status. Finally, a file's SHA-1 hash **is** its identifier, so unchanged files can be identified in this manner. It is possible to approximate this feature, if needed, using hooks. A custom attr could be attached to files that need such expansion, and an attr-hook defined in lua to perform the substitution. Another possibility may be an implementation similar to that used to handle platform-specific newline formats, generalising that to other kinds of filters. In any such implementation, it would be vital to ensure that the content of the file seen for commit has been sanitised to contain only the bare keyword in a 'canonical' form that is stable between revisions. ============================================================ --- wiki/Feature/Fast.mdwn f5ca9c5143b32c6816091d0be9bf1ebf75cce80c +++ wiki/Feature/Fast.mdwn f5c41dfdcff567c6064997005578212b14064245 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -10,9 +10,9 @@ Monotone is fast for many operations, in Monotone is fast for many operations, including most common ones in a workspace like `diff` and `status` and `commit`, but not universally so. Monotone's speed results are mixed, but improving rapidly. -Monotone has been implemented for robustness and correctness first, and optimisation later. It includes extensive internal consistency checking and revalidation of information (see [[FeatureRobustRepository]]) and this comes at some cost in performance. The implementations of some key internal operations have been initially written for clarity and simplicity rather than efficiency, and some are known to be downright wasteful of CPU. These are being optimised or rewritten as benchmarking shows where the hotspots are; this can be done with confidence on the basis of the extensive test suite that ensures correct behaviour is retained with new implementations. +Monotone has been implemented for robustness and correctness first, and optimisation later. It includes extensive internal consistency checking and revalidation of information (see [[Feature/RobustRepository]]) and this comes at some cost in performance. The implementations of some key internal operations have been initially written for clarity and simplicity rather than efficiency, and some are known to be downright wasteful of CPU. These are being optimised or rewritten as benchmarking shows where the hotspots are; this can be done with confidence on the basis of the extensive test suite that ensures correct behaviour is retained with new implementations. -Some operations are known to scale poorly on repositories with very deep histories, even though the problem may not be noticable on newer projects with shorter histories. The 0.30 release introduced major performance improvements as a result of applying this process to some key areas, and further work is ongoing to continue this process for more elements and internal operations. +Some operations are known to scale poorly on repositories with very deep histories, even though the problem may not be noticable on newer projects with shorter histories. The 0.30 release introduced major performance improvements as a result of applying this process to some key areas, and further work is ongoing to continue this process for more elements and internal operations. The user operations known to be slow include: @@ -20,13 +20,13 @@ The user operations known to be slow inc * `cvs_import` of long CVS histories into a fresh db (essentially the same problem, but without the workaround) * `mtn annotate` -PerformanceWork is active and ongoing to address these issues. Even for deep histories, common developer operations within a workspace are quite fast: usually the limiting factor is disk seek speed reading workspace files to check for changes. +[[PerformanceWork]] is active and ongoing to address these issues. Even for deep histories, common developer operations within a workspace are quite fast: usually the limiting factor is disk seek speed reading workspace files to check for changes. # Further Reference Manual and Tutorial Sections: - * [Inodeprints](http://venge.net/monotone/monotone.html#Inodeprints) + * [Inodeprints](http://monotone.ca/monotone.html#Inodeprints) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/LightweightBranches.mdwn 113eaacc5fdd34c6330a8b4aa2dec2280ccc1d99 +++ wiki/Feature/LightweightBranches.mdwn 525b7b92e477d7bdd5ed4d5d8d680a478cd56e95 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,11 +8,11 @@ Easy and cheap branching to allow parall # Supported -Monotone's implementation of branches is *extremely* lightweight, and quite different to that in many other systems. +Monotone's implementation of branches is *extremely* lightweight, and quite different to that in many other systems. Revisions can be in multiple branches (or none). Revisions can be added to branches long after they are first committed, perhaps after testing or code review to determine that they are suitable. Monotone separates completely the concept of a file's history (which is important for merging) from the concept of a branch (which is important for developers keeping track of the *purpose* of a particular development effort and view of the code). The [[BranchAnalogy]] describes the separation of these concepts. -Monotone also has very robust and powerful merging capabilities (see [[FeatureMerging]]). +Monotone also has very robust and powerful merging capabilities (see [[Feature/Merging]]). # Example Usage @@ -25,7 +25,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Branching and Merging](http://venge.net/monotone/monotone.html#Branching-and-Merging) + * [Branching and Merging](http://monotone.ca/monotone.html#Branching-and-Merging) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/LogReview.mdwn 912ff658418d96d163c6a900731a368318b014d9 +++ wiki/Feature/LogReview.mdwn ec30798076c100d6da5820c292387dd9de3a35e4 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,7 +8,7 @@ The ability to check and enforce style o # Supported -Monotone supports the validate_commit_message hook, which is passed a user's intended commit message and details of the revision about to be committed. Hooks are implemented in lua, and can make arbitrary programmatic assessements of the log message to decide whether to accept or reject it. The default hook simply rejects empty messages. +Monotone supports the `validate_commit_message` hook, which is passed a user's intended commit message and details of the revision about to be committed. Hooks are implemented in lua, and can make arbitrary programmatic assessements of the log message to decide whether to accept or reject it. The default hook simply rejects empty messages. Note that these hooks are run on individual developer machines where the commits are done, offline. These developers could remove the hooks and commit noncompliant messages if they wanted (though of course those messages are signed so this misbehaviour is clearly their own responsibility). @@ -20,8 +20,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [ValidationHooks](http://venge.net/monotone/monotone.html#Hooks) + * [ValidationHooks](http://monotone.ca/monotone.html#Hooks) Features and Requirements in other evaluations: + * [[FreeBSD]] [VCSFeatureLogReview](http://wikitest.freebsd.org/VCSFeatureLogReview). Note that the example given talks about "approved by: re" messages. While these might be appropriate in logs too, monotone has much more extensive and flexible mechanisms to handle approval of revisions for particular purposes and branches. See [[TrustFoundations]] and [[Feature/AccessControl]]. - * [[FreeBSD]] [VCSFeatureLogReview](http://wikitest.freebsd.org/VCSFeatureLogReview). Note that the example given talks about "approved by: re" messages. While these might be appropriate in logs too, monotone has much more extensive and flexible mechanisms to handle approval of revisions for particular purposes and branches. See [[TrustFoundations]] and [[FeatureAccessControl]]. ============================================================ --- wiki/Feature/LogTemplates.mdwn ac6cf94eb237a6feba601581e4a5240122907f6c +++ wiki/Feature/LogTemplates.mdwn e73c9eb141680876ff3f4fb076fbed40a30c06ac @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -10,7 +10,7 @@ This is not presently supported, but wou This is not presently supported, but would be simple to add - just nobody has gotten around to doing it yet. Like a number of other similar simple features and good ideas, this is one of the [[QuickieTasks]] that would be a great way for a new contributor to get used to the monotone code. -It is possible to test the commit message for compliance to rules (see [[FeatureLogReview]]), and it would also be possible to implement this using hooks. One suggestion would be to use a hook on other commands (like update) to copy the template to `_MTN/log` if it is empty. +It is possible to test the commit message for compliance to rules (see [[Feature/LogReview]]), and it would also be possible to implement this using hooks. One suggestion would be to use a hook on other commands (like update) to copy the template to `_MTN/log` if it is empty. # Further Reference ============================================================ --- wiki/Feature/MIMEtypes.mdwn 2689db6ba3008991214115f9644d5873d476a864 +++ wiki/Feature/MIMEtypes.mdwn 6219836853794712e19ca05dc46f635c81ded7bd @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -19,8 +19,8 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [File Attributes](http://venge.net/monotone/monotone.html#File-Attributes) - * [Hooks: Attribute Handling](http://venge.net/monotone/monotone.html#Hooks) + * [File Attributes](http://monotone.ca/monotone.html#File-Attributes) + * [Hooks: Attribute Handling](http://monotone.ca/monotone.html#Hooks) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/Merging.mdwn 64d10b953c8de7c089998d8adda7794d7790fa0a +++ wiki/Feature/Merging.mdwn 69beef33d039074a1101789869dd9e832fc0a61d @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,9 +8,9 @@ Automated and assisted merging of diverg # Supported -Monotone has very robust and powerful merging capabilities, which work based on the DAG history structure, independent of branches. These capabilities work regardless of how developers choose to use branches. +Monotone has very robust and powerful merging capabilities, which work based on the DAG history structure, independent of branches. These capabilities work regardless of how developers choose to use branches. -The merge, propagate and explicit_merge commands all access the same underlying merging capabilities, and differ only in how they select the revisions to be merged. merge picks multiple heads of the same branch, propagate merges the changes along one branch into another, and explicit_merge lets you pick whatever you like. +The merge, propagate and explicit_merge commands all access the same underlying merging capabilities, and differ only in how they select the revisions to be merged. merge picks multiple heads of the same branch, propagate merges the changes along one branch into another, and `explicit_merge` lets you pick whatever you like. The `update` command will use the same merge between a repository head and local changes in the workspace, but this is in general not recommended. Instead, recommended practice is to commit local changes first (multiple heads and explicit branches are cheap) and then merge with incoming revisions from other developers separately. @@ -33,7 +33,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Branching and Merging](http://venge.net/monotone/monotone.html#Branching-and-Merging) + * [Branching and Merging](http://monotone.ca/monotone.html#Branching-and-Merging) * [[DaggyFixes]] and [[ZipperMerge]] Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/Mirroring.mdwn 1f8f6f3389430038e71ea158bfd90288e6311520 +++ wiki/Feature/Mirroring.mdwn cb8ee0084b9413a090d846f3f62f52d912af6221 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -23,13 +23,13 @@ If either of these servers had new revis If either of these servers had new revisions, those revisions will be transferred to the developer's database, and then to the other server if it was not yet aware of them. In order to make them identical mirrors, use the branch pattern `'*'` for all syncs, otherwise more selective patterns can be used for partial replicas. -These servers are inherently peers, there is no particular need for any of them to be considered the [[MasterRepository]]. As discussed in that page, there is no particular need to back up either of these servers, their content can be restored from the other server, or from developer's databases - anything in a server database will also exist in one or more other databases where it was originally committed, at least. +These servers are inherently peers, there is no particular need for any of them to be considered the master repository. There is no particular need to back up either of these servers, their content can be restored from the other server, or from developer's databases - anything in a server database will also exist in one or more other databases where it was originally committed, at least. # Further Reference Manual and Tutorial Sections: - * [Network Service Revisited](http://venge.net/monotone/monotone.html#Network-Service-Revisited) + * [Network Service Revisited](http://monotone.ca/monotone.html#Network-Service-Revisited) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/NetworkSecurity.mdwn 594d7d68bf4ce54ccf7172a794ea5a052b833458 +++ wiki/Feature/NetworkSecurity.mdwn 7f11427d6f6396de5bdbea0d2e7282e64bb22055 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -22,7 +22,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Basic Network Service](http://venge.net/monotone/monotone.html#Basic-Network-Service) + * [Basic Network Service](http://monotone.ca/monotone.html#Basic-Network-Service) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/Obliterate.mdwn 132fb91bd79ee9985b57d55ab381d4f74e58cfac +++ wiki/Feature/Obliterate.mdwn 086944c440b38fa13960469f71c3534f30b7b457 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -25,6 +25,7 @@ Removing the revisions does not remove t If there are descendants, additional changes have been based on the bad revisions and they must also be removed. If they're unrelated and still wanted, they must be reapplied to an ancestor of the old revision (most likely using `pluck`). Removing the revisions does not remove the file content. This can be removed with a local sync to a new database, which won't transfer the now-unreferenced file content + $ mtn -d new.mtn db init $ mtn -d old.mtn sync file://new.mtn '*' ============================================================ --- wiki/Feature/Offline.mdwn a6d9631c23fcc0c19b2cb202957e145c90544ddc +++ wiki/Feature/Offline.mdwn cdd5986b2b5bded106adcb21e776b9dadcf9de5f @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -29,7 +29,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Storage and workflow](http://venge.net/monotone/monotone.html#Storage-and-workflow) + * [Storage and workflow](http://monotone.ca/monotone.html#Storage-and-workflow) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/Portable.mdwn e1d50d7cafdc0e0f89f0c78bce3629202afe47a9 +++ wiki/Feature/Portable.mdwn 9dbe7056d6aef5901a5dfc118cd0e45f8c7d6912 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,7 +8,7 @@ The VCS tools should be portable to run # Supported -Monotone is implemented in C++, and compiles and runs on all sorts of different kinds of Unix systems and Windows. It is packaged in a number of linux distribution and packaging systems, as well as [[NetBSD]] pkgsrc which itself supports a number of different systems: see [[BuildingViaPkgsrc]]. +Monotone is implemented in C++, and compiles and runs on all sorts of different kinds of Unix systems and Windows. It is packaged in a number of linux distribution and packaging systems, as well as [[NetBSD]] pkgsrc which itself supports a number of different systems: see [[Building/pkgsrc]]. # Further Reference ============================================================ --- wiki/Feature/Rename.mdwn 1dfa84a25d2b4e378a8feab86291bcaaf0b9d37b +++ wiki/Feature/Rename.mdwn f81ac92e084d27793772902720cf20e534dd97af @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -14,17 +14,15 @@ To rename a file: To rename a file: - $ mtn rename -e foo.c bar.c + $ mtn rename foo.c bar.c $ mtn commit $ mtn log bar.c -''(-e executes the change in the workspace filesystem as well as in monotone's history)'' - # Further Reference Manual and Tutorial Sections: - * [Manual Section Name](http://venge.net/monotone/monotone.html#[[SectionName]]) + * [Workspace Commands](http://monotone.ca/monotone.html#Workspace) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/RobustRepository.mdwn 023e466445479a3ad974398c8605a12ff49e64a7 +++ wiki/Feature/RobustRepository.mdwn 1c63ac339046b3831c3bcf49f7e3eb9a3ae957a2 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,7 +8,7 @@ The repository storage format should be # Supported -Monotone's repository is stored in an ACID-compliant [SQLite](http://www.sqlite.org) database file. All monotone operations that write to the database occur inside transactions, and so either happen completely or not at all. This includes not only normal VCS operations, but also administrative actions such as database schema upgrades that may occur from time to time as monotone develops. +Monotone's repository is stored in an ACID-compliant [SQLite](http://www.sqlite.org) database file. All monotone operations that write to the database occur inside transactions, and so either happen completely or not at all. This includes not only normal VCS operations, but also administrative actions such as database schema upgrades that may occur from time to time as monotone develops. Monotone is almost fanatically pedantic and paranoid about internal consistency checking, and has a strict policy of failing early. If any problems are detected during an operation, monotone will abort rather than risking committing bad information to the database. This is a very particular kind of robustness that favours historical integrity over user perceptions where abrupt errors are triggered. These events are generally fairly rare, and always of interest to the developers, even if it means that a more user-friendly error message needs to be emitted. @@ -16,7 +16,7 @@ Although the database storage layer is S Although the database storage layer is SQL, this is embedded within monotone; knowledge of SQL or the schema is invisible and irrelevant for all regular use. Even so, it is nice to know that SQL tools can be used when needed for extremely specialised operations. These circumstances usually amount to either debugging monotone, or specialised one-off administrative tasks that usually indicate the need for additional UI commands to be developed. The database storage layer and schema is also well isolated and abstracted within the monotone codebase: all the core algorithms and UI operations are entirely storage-agnostic, allowing other storage implementations or schema changes as needed. -See also: [[FeatureCompactRepository]] +See also: [[Feature/CompactRepository]] # Example Usage @@ -26,7 +26,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Database Commands](http://venge.net/monotone/monotone.html#Database) + * [Database Commands](http://monotone.ca/monotone.html#Database) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/SignedRevisions.mdwn 5e0760f7279533c01d8820e7eabc3ad215c7ca65 +++ wiki/Feature/SignedRevisions.mdwn a25d0a0312e86cc16ead3e1a88e8a23e20b537f0 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,7 +8,7 @@ Revisions and changes should be cryptogr # Supported -This is a primary and fundamental component of monotone. Revisions are identified by the SHA-1 hash of their ancestry+content, and additional metadata about these revisions is attached using signed certs. +This is a primary and fundamental component of monotone. Revisions are identified by the SHA-1 hash of their ancestry+content, and additional metadata about these revisions is attached using signed certs. # Example Usage @@ -22,7 +22,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: - * [Certificates](http://venge.net/monotone/monotone.html#Certificates) + * [Certificates](http://monotone.ca/monotone.html#Certificates) * [[TrustFoundations]] and [[UsingCerts]] Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/Symlinks.mdwn 180df0600f90c1e0e095636fc8a08a6f42137e15 +++ wiki/Feature/Symlinks.mdwn 6def6a91992560aead175b4134fec30b34a3c606 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,7 +8,7 @@ Store Unix Symbolic Links as versionable # Partially Supported -Monotone ignores symlinks by default, but extensions to store these can be implemented using attrs and hooks. These are under active development and in use at the moment and may be integrated into a future release. +Monotone ignores symlinks by default, but extensions to store these can be implemented using attrs and hooks. These are under development and in use at the moment and may be integrated into a future release. # Example Usage ============================================================ --- wiki/Feature/Template.mdwn 11a1dc401fbfe8b5e08722ecb19b895e352276a7 +++ wiki/Feature/Template.mdwn 84c781591b290cfa861e583cb507bfb8bb4a995e @@ -24,7 +24,7 @@ Manual and Tutorial Sections: Manual and Tutorial Sections: -* [Manual Section Name](http://venge.net/monotone/monotone.html#SectionName) +* [Manual Section Name](http://monotone.ca/monotone.html#SectionName) Features and Requirements in other evaluations: ============================================================ --- wiki/Feature/VendorBranches.mdwn 633542b06c347681cd56e9596837b82c85400887 +++ wiki/Feature/VendorBranches.mdwn c57151610ef76c11448728d29ec4fced52ff7e99 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -17,7 +17,7 @@ There are two aspects to this requiremen # Example Usage -*under construction* The [[VendorBranchPattern]] page (will) contain detailed recommendations for [[BestPractices]] in how this should be done. +The [[VendorBranchPattern]] page contains detailed recommendations for [[BestPractices]] in how this should be done. # Further Reference ============================================================ --- wiki/Feature/WebInterface.mdwn 9294b668202df884f61bd3b643b20c9fad27bfdf +++ wiki/Feature/WebInterface.mdwn f925ce7ae0e820861f9a23943bade74439708307 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] This page is one of many describing [[EvaluationFeatures]] that may be useful when comparing monotone to other similar (and not-so-similar) VCS systems. @@ -8,13 +8,13 @@ A web-based interface should allow for e # Supported -There are a number of [[InterfacesFrontendsAndTools]] that work with monotone, including several web-based ones. Monotone's own sources can be browsed using [ViewMTN](http://grahame.angrygoats.net/viewmtn.shtml), and there is also a [Trac plugin](http://www.ipd.uni-karlsruhe.de/~moschny/TracMonotone/) under development. +There are a number of [[InterfacesFrontendsAndTools]] that work with monotone, including several web-based ones. Monotone's own sources can be browsed using [ViewMTN](http://grahame.angrygoats.net/viewmtn.shtml), and there is also a [Trac plugin](http://tracmtn.1erlei.de/) under development. # Example Usage - - * [Recent monotone activity, via [[ViewMTN]]](http://viewmtn.angrygoats.net/branch.psp?branch=net.venge.monotone) - * [Current monotone HEAD revision](http://viewmtn.angrygoats.net/headofbranch.psp?branch=net.venge.monotone) - * [Trac-monotone demonstration](http://trac.h975245.serverkompetenz.net/) + + * [Recent monotone activity, via [[ViewMTN]]](http://viewmtn.angrygoats.net/all/branch/changes/net.venge.monotone) + * [Current monotone HEAD revision](http://viewmtn.angrygoats.net/all/branch/changes/net.venge.monotone) + * [Trac-monotone demonstration](http://tracmtn.1erlei.de/browser) * [Recent monotone activity, via CIA](http://cia.navi.cx/stats/project/monotone) # Further Reference ============================================================ --- wiki/VendorBranchPattern.mdwn 5df1301f79eb01e24f3501dd2fdcab509eea7b08 +++ wiki/VendorBranchPattern.mdwn f51792f8e19e6f916e9a38f81e068894253f4c03 @@ -1,16 +1,18 @@ -[[!tag migration-auto]] +[[!tag migration-done]] -If you are working on a project that has been partitioned, give each partition a branch. A partition could be upstream code. - -Then merge_into_dir each partition into your project. Use explicit_merge to integrate releases. If you have made some local changes that didn't make sense to push back upstream, monotone will try to maintain them. - -For example, let's say your project 'com.example.foo' uses sqlite. Instead of dumping sqlite into /sqlite of your project and committing it, give sqlite into a branch of it's own. Perhaps 'org.sqlite' is a good name. You can use this branch to track the sqlite development: perhaps only tracking releases, perhaps pulling from the sqlite VCS using tailor or some other magic. Tag releases that you are interested in with meaningful tags 'sqlite-3.2.5'. - -Now, merge_into_dir org.sqlite com.example.foo sqlite. - -You can use the org.sqlite branch to play around with sqlite, and when you find a new version that you want to try, you can use explicit_merge (or propagate) to bring it into com.example.foo. +If you are working on a project that has been partitioned, give each partition a branch. A partition could be upstream code. +Then `merge_into_dir` each partition into your project. Use `explicit_merge` to integrate releases. If you have made some local changes that didn't make sense to push back upstream, monotone will try to maintain them. + +For example, let's say your project 'com.example.foo' uses sqlite. Instead of dumping sqlite into /sqlite of your project and committing it, give sqlite into a branch of it's own. Perhaps 'org.sqlite' is a good name. You can use this branch to track the sqlite development: perhaps only tracking releases, perhaps pulling from the sqlite VCS using tailor or some other magic. Tag releases that you are interested in with meaningful tags 'sqlite-3.2.5'. + +Now execute + + $ mtn merge_into_dir org.sqlite com.example.foo sqlite + +You can use the org.sqlite branch to play around with sqlite, and when you find a new version that you want to try, you can use `explicit_merge` (or `propagate`) to bring it into com.example.foo. + Back to [[BestPractices]]. -------- + +> ''A step-by-step example would be a nice enhancement to this page and to the explaination given in the manual. A counter-example to doing nested checkouts with pro's and con's would help illustrate the benefits of `merge_into_dir`.'' -- [[People/ChadWalstrom]] -## Comments -''A step-by-step example would be a nice enhancement to this page and to the explaination given in the manual. A counter-example to doing nested checkouts with pro's and con's would help illustrate the benefits of merge_into_dir. -- [[People/ChadWalstrom]]''