On 9/14/2012 1:04 PM, Boggess, Rod wrote:
[snip discussion of admin privileges on installation]
Second, the discussion of Windows explorer integration in 5.2 does
not explain much of anything, i.e.,
what the specific commands in the context menu do or what the overlay
icons mean (the latter I think I know).
Here, as elsewhere, my biggest uncertainty is whether commands
operate on the working/local copy,
the repository, or some combination. What's the difference between
forget and remove? If revert files
operates on the working copy (my guess), what are the implications
for branching and merging? I looked
around for similar entries in the more fully documented Workbench
section 5.4. esp the file context
menus 5.4.10, but didn't find much--it does discuss revert.
I don't have the text open yet (still trying to install Thg in
Ubuntu). That said, the overlay icons are the green checkboxes and red
X's on the files and folders under version control. The green checkbox
means that those files and folders match the version of the files in
the current tip of the repository. Red X's mean they do not match
(and, presumably, that a commit should be performed).
For completeness I'll note that the absence of an overlay indicates the
file is not under version control.
The context menu for Tortoise, as with most Explorer context menus,
apply to the directory (and files within that directory) where the
context menu is invoked. (Is this enough for you to understand whether
that would be a local or a remote repository, or do I need to explain
why this always implies one? I won't tell you which, here, for fear of
contaminating your perception.)
My main concern was whether operations were on the local repository or
the working files, not local vs remote repository. Because everything
is in the same directory hierarchy it's a little hard to refer to this
cleanly, but mechanically by "repository" I mean the stuff under .hg
whereas working files means everything else.
Sorry for being obtuse here, but what are your expectations or fears
that revert might have on branches and merges? Have you looked at any
documentation on version control or Directed Acyclic Graphs (DAGs)?
I'm asking you this before I inquire from the author who their target
audience is, but I'm assuming they anticipated folks who had some
working knowledge of version control. Since you don't know, I'm
assuming you don't. Ignoring extensions that can be layered on
Mercurial, the core of any version control system is to maintain the
history of software change revisions, or changesets (a block of
changes in several files). Reverting a file merely means you wish to
restore that file to its state from the last commit (changeset). If
you specify a revision to revert to, the working copy of the file is
restored to the state of that commit (or changeset). If you revert to
a previous revision, then do a commit, the newly committed changeset
will show a new set of changes that undo all of the changes since the
revision to which you reverted. Does that help explain any
implications to branches and merges? If not, should I go back and
explain exactly what branches and merges are in relation to a changeset?
I know about DAGs, branches and merges, and the way DVCS uses UUIDs to
keep track of things. Of course, the reader of the manual may not.
Concerns with revert:
1. It might be an operation on the repository, e.g., effectively
uncommitting a previous commit or otherwise modifying the history.
From your discussion, that's not the case.
2. Reverting the local copy might rebase the revision. Say the file
has versions 1, 2, and 3. Currently it's at version 3 but I revert
it to 1. Does the system regard this as a v1 file, with future
changes I make being a branch off v1 on commit, or a v3 file with
uncommitted changes that happen to make it identical to v1? I'm
pretty sure the answer is the latter. Or, in a more natural
language for Hg, it doesn't move the tip.
3. Or perhaps the revision will operate on the whole changeset at once,
updating all the files in the directory (even if I revert a single
file), or that directory plus its subdirectories, or the whole
project (which might include directories higher up)? Pretty sure
just the file is affected.
Some of these concerns arise by analogy with other systems that allow
mixed revisions in the same directory. On reflection it seems unlikely
a DVCS would allow such a thing, but that reflection triggers the
thought the the operation might be a whole changeset at a time, and
hence concern 3.
Also unclear to me are update, synchronize and recovery.
Update (with "Discard local changes") amounts to a revert on a whole
changeset (as opposed to a single file). It also moves the tip or
working changeset to the specified revision. (If you don't specify
"Discard local changes", then it merely moves the working changeset or
tip to the specified revision, while your working directory contains
all of the current code. If you are up to date on revision 5, revert
to version 3, then edit the code and do a commit, it will create a
second child to revision 3, in essence, creating a branch there. That
commit will include all of the changes in 4 and 5 and the changes you
just made. Ugly.)
Is the scope of the change the entire project, including directories
above the current one, or the hierarchy rooted at the focal folder, or
just that folder?
Stay away from the recover command. It's only used when you
synchronize and you have a network failure that prevents the synch
from completing. (Or other, similar failure.) Synchronize is unique to
distributed version control systems, as opposed to the more classical
approach. In a classical approach, there is a canonical server that
hosts the version control system. Everyone pushes their changes to
that unique location. If you don't have access to the server, you
cannot commit. When you commit a revision (and create a new
changeset), everyone sees it immediately. The server is the shared
resource. In DVCS, every developer has their own server with their own
unique history of changes (in the form of changesets or revisions).
When two developers cooperate, they must at some point synchronize
their work. This usually consists of pulling, merging, verifying
operability (locally), committing (locally) changes required to
maintain operability, then a final push. Pulling and pushing are
synchronizing activities that take place between two repositories that
share a common history of origin. (You can't really synchronize a
Paint.Net Software repository with the DWPF Nuclear Remediation
Control Software repository because they don't have a shared starting
point.) Here, the changesets are the shared resource which must be
synchronized. This may be explained elsewhere, but in case it isn't,
this "everybody has their own copy" philosophy allows developers to
commit (locally) changes that may not yet be able to compile. "Commit
often!" is the mantra of DVCS. You don't have to synch until you have
a fully functional version, but you don't want to risk losing your
work (or your change history). With a DVCS, you can eat your cake and
have it, too. If you do this on a classical VCS, mobs will line up
outside your cubical with pitchforks and torches.
I think you've got 2 different senses of synchronize there. One is the
command itself; the other is the sequence of operations that developers
would perform when aligning their code, which starts and ends with a
sync command and has other stuff--merging, testing, committing--in between.
My guess is that the command ensures that each repository has the union
of the changesets of each. Or does it merge too? And perhaps it only
trades changesets that are relevant for the 2 respositories respective tips?
In a classical VCS you can do your flakey work in a branch to avoid
hosing everyone else.
5.4 is generally much better, but does not always explain things,
e.g.,
5.4.1 Workbench menus just lists the menus. I think most of the items
are explained further down in the
context of toolbars.
Having this stuff documented in the manual would be nice; some kind of
tool tip might be even more
useful.
I agree, but I'm only focusing on the documentation here. I believe I
can add a small blurb in the docs that (briefly) describe the menus.
If nothing else, we should be able to say that they're demonstrated or
explained below.
A small blurb would be nice, and if it's really small would be amenable
to tooltips. I'm not even sure tooltips on a menu item are possible.
Ross
------------------------------------------------------------------------------
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
_______________________________________________
Tortoisehg-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
