# # # patch "wiki/ChangeLog.mdwn" # from [013e254dd7aab96ece36aed1a2ddf0422daa3d5d] # to [7f2ab77cac1e9f6a74a8306318f4daf1a380c5c6] # # patch "wiki/CherryPicking.mdwn" # from [4de76b340edaa81c60a4a75b7e989f0cd5c066c3] # to [347fe6feda355a7b42821f6264990ddba8b3e5fb] # # patch "wiki/QuickieTasks.mdwn" # from [ff377ef329b32d3fbd1a0406888bd633660cc457] # to [c39f95792b259543cc95a4ff735f3686673c51f6] # ============================================================ --- wiki/ChangeLog.mdwn 013e254dd7aab96ece36aed1a2ddf0422daa3d5d +++ wiki/ChangeLog.mdwn 7f2ab77cac1e9f6a74a8306318f4daf1a380c5c6 @@ -1,6 +1,6 @@ -[[!tag migration-auto]] +[[!tag migration-done]] -This is a first little piece of emacs-code, to achieve the task of writing log messages to `_MTN/log` instead of `ChangeLog` if appropriate. (Note that [http://download.gna.org/dvc/ DVC] already includes a similar feature, bound to C-x V a by default.) +This is a first little piece of emacs-code, to achieve the task of writing log messages to `_MTN/log` instead of `ChangeLog` if appropriate. (Note that [DVC](http://download.gna.org/dvc/ already includes a similar feature, bound to `C-x V a` by default.) Look at the source for a way to use it. From now on use `mtn-add-change-log-entry` instead of `add-change-log-entry`. `mtn-add-change-log-entry` will try do the right thing. ============================================================ --- wiki/CherryPicking.mdwn 4de76b340edaa81c60a4a75b7e989f0cd5c066c3 +++ wiki/CherryPicking.mdwn 347fe6feda355a7b42821f6264990ddba8b3e5fb @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] "Cherry picking" is an extension to merge that allows changes between arbitrary versions to be merged into the current version. @@ -8,4 +8,4 @@ This is not a full cherry-picking soluti This is not a full cherry-picking solution in the sense that some other VCSs use the term. In particular, the revisions being plucked are recorded in the changelog template in preparation for a later `commit`, but other than this, `pluck` operations are not recorded directly in the ancestry or otherwise in the metadata, and are therefore not recognised in any special way by later commands. This can be important when later merging or repeatedly plucking changes between branches. +Even so, `pluck` is very useful, and more advanced developer practices are expected to evolve around it. Some examples of these practices are discussed in the [[DaggyFixes]] page. -Even so, `pluck` is very useful, and more advanced developer practices are expected to evolve around it. Some examples of these practices are discussed in the DaggyFixes page. ============================================================ --- wiki/QuickieTasks.mdwn ff377ef329b32d3fbd1a0406888bd633660cc457 +++ wiki/QuickieTasks.mdwn c39f95792b259543cc95a4ff735f3686673c51f6 @@ -1,4 +1,4 @@ -[[!tag migration-auto]] +[[!tag migration-done]] # quickie tasks @@ -6,26 +6,46 @@ So, here are some smaller tasks, that ve So, here are some smaller tasks, that very much need doing, that fit the above bill: - * new commands `mtn detach` (which removes the _MTN directory from a workspace), and `mtn attach -r ` (which turns a normal directory into a workspace at the specified location). These are useful for export/import type workflows. + * new commands `mtn detach` (which removes the `_MTN` directory from a workspace), and `mtn attach -r ` (which turns a normal directory into a workspace at the specified location). These are useful for export/import type workflows. + * new developer's command `mtn make_man_page` that dumps out the --help texts in man page format. Update build process to use this command to generate a real man page and install it. - * header file audit (only #include things we actually use, use when possible, etc.) + + * header file audit (only #include things we actually use, use `` when possible, etc.) + * `mtn rename --guess` -- try to figure out what files have been renamed by matching up missing and unknown files with the same checksums + * `mtn list duplicates` -- list files that have the same checksum (duplicate content) in a given revision (or the workspace) + * `mtn clean --unknown --ignored` to remove files of each type from the workspace; handy for a really aggressive "make clean", and for plaforms without xargs or where there might be spaces in filenames so that `mtn ls unknown | xargs rm` is hard or dangerous. + * `mtn diff --ignore-whitespace` - * make the diff header contain more helpful contextual information -- some thoughts are in [http://lists.gnu.org/archive/html/monotone-devel/2006-01/msg00194.html this email]. it might take a bit of discussion to figure out the nicest format - * 'db check' now includes a call to the sqlite [http://www.sqlite.org/pragma.html#debug PRAGMA integrity_check], but we need a test for this; check out Message-ID in the list archives. + + * make the diff header contain more helpful contextual information -- some thoughts are in [this email](http://lists.gnu.org/archive/html/monotone-devel/2006-01/msg00194.html). it might take a bit of discussion to figure out the nicest format + + * 'db check' now includes a call to the sqlite [PRAGMA integrity_check](http://www.sqlite.org/pragma.html#debug), but we need a test for this; check out Message-ID in the list archives. + * more inodeprints UI -- maybe "inodeprints on/off/auto/refresh", where "auto" turns them on or off depending on the size of the tree (and is used by default at checkout time)? + * support for .mtn-template. This is a versioned file, that is used as the default for log messages. This might be helpful so you can put in fields for bug numbers, standardize your log message format, etc. Implementation is to make it the default value of _MTN/log. One tricky bit is that commits should be canceled if given an empty or _unchanged_ log message; currently they are canceled only on an empty log message. + * script that wraps monotone and gathers statistics on usage, that people could use to help us make UI decisions. Just recording commands would be good; taking notes on things like how many files were edited in a commit, whether any given merge or update had conflicts, etc. would be even cooler. + * make `--debug` output contain timestamps for each event, possibly with another option; this might help provide information about performance issues and where time is being taken between key steps. + * include tests in the test suite to ensure that various external tools (like tailor or buildbot) still work with us; perhaps track their integration code (eg, monotone.py from tailor) and attempt to keep it up to date with changes in HEAD. + * two-argument disapprove: should be some way to apply disapprove to a range of revisions, not just a single one. (basically just means committing the changeset diff(LASTREV,FIRSTREV) as a child of LASTREV.) be careful about merge nodes in the span to disapprove. + * add support for more merge tools -- SVK is one source of these, they support a number that we don't. see SVK/Resolve/* in their source tree. + * add a test for context diff output - * write a test for any bugs in the [https://savannah.nongnu.org/bugs/index.php?group=monotone tracker] labeled [NEED TEST]. - * **IN PROGRESS**: Emacs code that makes C-x 4 a drop one into _MTN/log instead of ChangeLog. **See ChangeLog** - * `mtn status -rREV` and `mtn checkout --nofiles`; see [http://lists.gnu.org/archive/html/monotone-devel/2006-08/msg00311.html this discussion] and [http://thread.gmane.org/gmane.comp.version-control.monotone.devel/7752/focus=7756 this one]. + + * write a test for any bugs in the [tracker](https://savannah.nongnu.org/bugs/index.php?group=monotone) labeled [NEED TEST]. + + * **IN PROGRESS**: Emacs code that makes C-x 4 a drop one into _MTN/log instead of ChangeLog. **See [[ChangeLog]]** + + * `mtn status -rREV` and `mtn checkout --nofiles`; see [this discussion](http://lists.gnu.org/archive/html/monotone-devel/2006-08/msg00311.html) and [this one](http://thread.gmane.org/gmane.comp.version-control.monotone.devel/7752/focus=7756). + * automatic updating of the tutorial section of the texinfo docs so that program output, etc. is kept current +See also: [[InterfacesFrontendsAndTools]] that don't exist, but if they did they would make using monotone just that much more awesome. -See also: InterfacesFrontendsAndTools that don't exist, but if they did they would make using monotone just that much more awesome.