>First, it would be good if the installation section for Windows, 2.2.1, mentioned that admin privileges > were required (probably only post-XP?).
I've never tried installing software on Windows as a non-admin. I know that's possible in some special cases with .Net apps, but I've never done it. You aren't talking about right-clicking and choosing Run as administrator..., correct? I don't remember having to do that. Though it's so second nature to everything I do in W7, that I may have done it while on autopilot. >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). 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.) 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? >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.) 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. >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. ------------------------------------------------------------------------------ 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
