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.
I just realized I never answered your question about the difference
between forget and remove. Forget tells Mercurial to stop tracking
future changes to the specified file. Remove says to stop tracking
future changes to the file and delete the file from the local disk.
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?
I think you misunderstand what the Synchronize context menu does for you
in TortoiseHg. It isn't a command, but rather a popup dialog box. The
dialog box allows you to choose a remote repository and perform pull and
push commands. I do all my work from the Workbench, and haven't used
this. As such, I can't say with certainty that it doesn't merge, but I
don't see any capability to merge - if it's there, it's hidden. I'll
have to play with this and see what I can find out.
I didn't realize Subversion played with the history. In configuration
management theory, that's a serious no-no. The commands in Mercurial do
not permit modification of the history. Once a revision is committed,
it's sacrosanct. You can enable certain extensions (plug-ins) that will
allow you to manipulate certain aspects of the history, but these are
advanced uses, not part of the core of Mercurial, and they are used
"caveat emptor". Instead, everything you do in Mercurial takes place in
the mutable working directory. If you revert a file to a previous
revision, you revert the file in the working directory. If you merge two
revisions from separate branches, your merge results go in the working
directory. In both cases, to make the change a permanent part of
history, you have to follow with a commit. No flakery allowed.
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
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Tortoisehg-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
