If you see any changes you want to bring into your copy of the repo use the pull command: To update your local copy of the repo, first take a look at the changes that have been made to the source repo using the incoming command: As changes are made to the repo you copied from you will probably want to update your repo with those changes. So now you have a copy of a repo stored locally. The tip revision is the changeset most recently added to the repository (and therefore the most recently changed head) and the tip tag is special and cannot be renamed or assigned to a different changeset. There is a head changeset for each branch that exists in the repo, and there can be multiple heads with the same branch name. Changesets that don’t have any children are called head changesets, or heads. The commit command creates a new changset, assigns it a rev and ID, and records the parent of the changeset (except in the case of the root changeset). So when working with a local repo it is easier to type the small numbers used to identify a changeset, while still having a unique ID across all copies of the repo in order to identify a changeset. Changesets are assigned revision numbers, which are unique to a repo but not to other copies of the repo, and an identifier, consisting of 12 hex digits, which is unique across all copies of a repo. The term is often abbreviated to change or cset and is also referred to as a revision or a rev. Every repo is complete and independent from any other repos for the project.A changeset is an identified set of changes made to one or more files in a repo. Hg refers to the set of files that make up a project as a repository, or repo. You would then have to take care not to push that changeset, though.Mercurial, a/k/a Hg, is a source code management tool. You could even just commit the changes, then update back to the parent and commit other work there, leaving the changes in a stubby anonymous branch - hg commit -m 'temporary branch' & hg up $(hg log -r 'parents(.)' -template '') (although it may be easier to do manually!). You could also use the queues extension, but that's using a sledgehammer to crack a nut. You can make this smoother by installing the shelve extension, the attic extension, or some other relative. The simplest thing is simply to use hg diff on the files to produce a patch describing them, which you keep somewhere safe, then hg patch -no-commit to reapply that patch when you want the changes back. If you are prepared to move the changes aside, you have another set of options. If you have a large number of files to exclude, or will be excluding them from many commits (eg for a permanent change to a local configuration file), look at the exclude extension. If they are already tracked, then you can specifically exclude them from commits with hg commit -exclude foo.txt. If the files are new, that's easy - just don't hg add them. If you keep them in the working copy, incoming changes will work fine, so you just need to avoid creating outgoing changes, and that means avoiding committing them. Which you choose depends on whether you want to have these changes available as you work. The first is to keep the changes in your working copy, but not push them, and the other is to put them aside, out of the working copy. So, for local changes that you don't yet want to share with other developers, you have two approaches. You refer to an "inability to merge with them" - if you have an uncommitted change to some file, and you pull and update a change to that file, Mercurial will start the merge process just as if you had committed it, then asked for a merge. I don't believe uncommitted changes are intrinsically a bad thing.
0 Comments
Leave a Reply. |