On Mon, 2012-09-17 at 08:51 -0400, Boggess, Rod wrote: > > > > > From: Ross Boylan [mailto:[email protected]] > Sent: Friday, September 14, 2012 7:56 PM > To: Boggess, Rod > Cc: [email protected] > Subject: Re: [thg] confusion specifics > > > > > On 9/14/2012 1:04 PM, Boggess, Rod wrote: .....
> 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. "stop tracking future changes" sounds as if the file remains but does not change. Is that what you meant, or does the file also "disappear" from future revisions? In other words, if X1 is the file X as committed at version 1, then does this sequence commit (rev 1) forget X commit (rev 2) pull repository at a new location (which was previously empty) result in X1 being at the new location? Given the wording, same question applies if the step is remove X rather than forget. > > > > 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. > Are my suppositions about revert correct, namely that revert affects the local file only, bringing it back to the requested revision, but leaving it based on the tip? > > > 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? Still wondering about that. > > > > 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. Thanks for clarifying (also in your other response). Becaue of my uncertainty about what different operations did I was reluctant to try them out and see what happened. > > > > I didn’t realize Subversion played with the history. I think it can; I know some VCS's do. I've never used those functions. There are several scenarios where it might make sense to modify the history: 1) You committed a confidential file and don't want anyone to ever be able to retrieve it. This functionality suggests the (incorrect) alternate reading of forget/remove as operations on the repository. 2) You want to change the comment on an earlier commit. 3) You want to merge or clean up your changesests. (I think DARCS in particular lets you do that, though, again, I never have tried.) If anyone has actually accessed the changes, especially in a DVCS, these are pretty funky operations, but, if they haven't, the operations might be useful. Ross > 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. ------------------------------------------------------------------------------ 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
