Repository head:
A branch label names the tip revision of its branch.
src log and src list skip ignored and unregistered files in arguments.
- The embedded help has been enriched and now fearures multiple topics.
+ The embedded help has been enriched and now features multiple topics.
! works to negate patterns in ignore files.
git status -a forces status display of all files, including I and ?.
* should be possible to range-restict a tag or branch listing.
-* vc.el
+* break up the tag and branch commands - separate delete/list/rename.
+
+* vc-src.el
+
+* Parse RCS files directly rather than relying on rlog(1).
KNOWN BUGS
-* chungy reports timestamp issues messing up status on ZFS.
+* chungy reports timestamp issues messing up status on ZFS. Produces
+ false 'M' status when the file is actually unmodified. Consider
+ checking content when M is returned.
+
intro -- Basic concepts: commits, tags, branches. The form of commands.
revisions -- How to specify ranges of commits to operate on.
commands -- a summary of the commands.
+commit -- how to commit changes to a file.
status -- details about the src status command.
ignores -- .srcignore files and their uses.
""",
branching, parent and child commits do not necessarily have
consecutive numbers.
+Commits will always be be added to the tip of the current branch.
+You can change the current branch by either checking out a revision
+that is on that branch, or using a 'src branch' command to
+explictly change the current branch.
+
You can assign tags (names) to point to commits. They too can be
renamed later or deleted.
The omission of 'src remove' is a deliberate speed bump.
""",
"status": """
+src status [-a] ['file'...]
+
The status command shows you the version-control status of files. It is
designed to be useful for both humans and software front ends such as
Emacs VC mode.
The -a option forces status listing of all files. This differs from
'src status *' because the latter will not see dotfiles and thus not list
the status of them.
+""",
+ "commit":"""
+src commit [- | -m 'string' | -f 'file' | -e] ['file'...]
+
+The commit command is how you add revisions to your file history. It
+always adds the contents of the workfile as a revision to the tip of
+the current branch.
+
+You also use commit on files that have not been registered to start
+an SRC history for them.
+
+When you commit, you must specify a change comment to go with
+the revision. There are sevaral ways to do this.
+
+The '-m' option to the command takes the following string argument
+as the comment. The '-' option takes the comment text from standard
+input. The -f option takes the comment from a named file.
+
+If you use none of these, or if you use one of them and the -e option,
+SRC wlll start an editor in which you can compose the comment. Text
+specified via -m, -f, or - becvomes the initial contents of the comment.
+
+SRC respects the EDITOR variable and calls it on a tempporary file
+to create your comment. Th file will have a footer including its
+name and revision which will be discarded when you finish editing.
+
+If you commit to multiple files at once, separate changes will be
+registered for each one, and you may get a separate edit session for
+each (if you have not set the comment text with options, or have
+forced editing with -e). This is a major difference from other VCSes,
+which are usually designed to create changesets common to multiple
+files.
+
+'ci' is a synonym for commit.
""",
"ignores" : """
You can have a file named .srcignore containing the names of files that
src - simple revision control
== SYNOPSIS ==
-*src* [command]
+*src* [command] [revision-spec] ['file'...]
== DESCRIPTION ==
SRC (or src) is simple revision control, a version-control system for
single-file projects by solo developers and authors. It modernizes the
-venerable RCS, hence the anagrammatic acronym. The desigh is
+venerable RCS, hence the anagrammatic acronym. The design is
tuned for use cases like all those little scripts in your ~/bin
directory, or a directory full of HOWTOs.
to look familiar if you have ever used Subversion, Mercurial, or Git.
SRC interprets the EDITOR variable in the usual way, using it to spawn
-an editor instance when you perform a commit.
+an editor instance when you perform a commit or amend.
== COMMAND SUMMARY ==
By default, history files are kept in a hidden subdirectory named
".src". But if you have an RCS subdirectory and no .src, SRC
-will quietly operate on the files in the RCS directory.
+will quietly operate on the files in the RCS directory in a
+completely backward-compatible way.
== DEBUGGING OPTIONS ==
These will be of interest mainly to developers.
-A '-d' option before the main command word turns on debugging
+A '-d' (debug) option before the main command word turns on debugging
messages; it can be repeated for higher debugging levels.
A -S (sandbox) option can be used to set the repository directory
== REQUIREMENTS ==
-The RCS tools at version 4 or later must be installed and accessible
-on your path; rcs-fast-import(1) at version 1.0 or later is required
-to support the src fast-import command.
+SRC is written in Python and requires 2.7 or later. The RCS tools at
+version 4 or later must be installed and accessible on your path. The
+rcs-fast-import(1) tool at version 1.0 or later is required to support
+the src fast-import command.
== LIMITATIONS ==
-The 'branch' command is not yet fully implemented; it is described here to
-document the UI design choice.
+branch delete is not yet implemented.
src uses a trick with utime(2) to make distinguishing between modified
and unmodified files fast. The trick has flaky failures under ZFS,
though none have been seen under ext3, ext4, or xfs. This affects
-nothing other than 'src status'; when the tricj fails files may
+nothing other than 'src status'; when the trick fails files may
show as modfied ('M') when they should show as unmodified ('.').
== REPORTING BUGS ==
projects / src.git / commitdiff