monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] File log command-line UI thoughts


From: Kevin Smith
Subject: [Monotone-devel] File log command-line UI thoughts
Date: Thu, 13 Nov 2003 09:25:30 -0800
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20031024 Thunderbird/0.2

As you know, I am interested in a command that will list the history of a single file. Since I come from a world with essentially no branches, it has been an interesting exercise for me to blend my concept of a linear history with the world of monotone branching.

I think the sane thing to do is to allow you to pull the history for a given file back to the first point that it had two ancestors. At that point, it would stop and tell you the ids of the two ancestors.

From there, you would have to run another command to ask for the history of the ancestor you wish to follow, which would show you that history back to the merge before that. In a GUI, this could be bundled in a friendly way.

Since the 'log' command is taken for manifest use, my first thought is to name this new command 'history'. Other options would be extending the log command to handle files, or naming it 'filelog'. Regardless of the name, the command might look like:

  history <filename>
  history <file-id>

As with filediff, we have ambiguity here. Perhaps the universal rule should be that if a parameter can be a filename or file-id, it should first look for a local file in the workspace by that name, and if there isn't one, it should assume it is a file-id? Or should we look for a unique completion first, then default to an existing filename, and finally fall back to showing a list of possible completions?

Or should we require all id's to be prefixed with 'revision', as in:

  history revision 23c3

That seems like needless typing, to me. It would be great to be consistent across all commands, but that might mean tweaking the existing commands, which I know might be painful. Less painful now than after v1.0, of course.

Thoughts?

Kevin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]