Revision 2580 isn&#39;t necessasrily the parent revision of 2581.  It&#39;s easy to check if it is, of course, but easier yet is to just do:

    hg log -p -r 2581

That compares 2581 to its (first) parent revision no matter what it is, and most clearly encompasses the answer to the question *&quot;what the hell did 2581 do?&quot;*

    hg diff -r 2580 -r 2581

This is a wrong example. The revision 2580 can be in another branch and you get diff between two branches.

Use 

    hg log -p -r 2581
or `hg diff -c 2581`

The difference between them in the first lines. Hg log also show information about changeset (parent, author, date, ...)

I prefer second variant `hg diff -c ...` because it can store to patch files.

`hg diff -c 2581 &gt; revision_2581.patch`

Another solution is to use revset notation which IMO is a better solution as you can use it in more places consistently (ie you don&#39;t need to know about `diff -c` and `log -p` ).

    hg diff -r &#39;last(ancestors(2581),2)&#39;

Yes that is rather verbose compared to -c (for diff) and -p (for log).

However mercurial allows you to create revset aliases

In your `.hgrc`:

    [revsetalias]
    
    next(s) = descendants(s, 1)
    prev(s) = last(ancestors(s),2)

Now you can do

    hg diff -r &#39;prev(2581)&#39;
    hg log -r &#39;prev(2581)&#39;



These days, I have been reading a lot the [C++ F.A.Q][1] and especially [this page][2].

Reading through the section I discovered a &quot;technique&quot; that the author calls &quot;exception dispatcher&quot; that allows someone to group all his exception handling in one handy function:

    void handleException()
    {
      try {
        throw; // ?!
      }
      catch (MyException&amp; e) {
        //...code to handle MyException...
      }
      catch (YourException&amp; e) {
        //...code to handle YourException...
      }
    }
     
    void f()
    {
      try {
        //...something that might throw...
      }
      catch (...) {
        handleException();
      }
    }

What bothers me is the single `throw;` statement: if you consider the given example then sure, it is obvious what it does: it rethrows the exception first caught in `f()` and deals with it again.

But what if I call `handleException()` on its own, directly, without doing it from a `catch()` clause ? Is there any specified behavior ?

Additionally for bonus points, is there any other &quot;weird&quot; (probably not the good word) use of `throw` that you know of ?

Thank you.


  [1]: http://www.parashift.com/c++-faq-lite/
  [2]: http://www.parashift.com/c++-faq-lite/exceptions.html

What does a single &quot;throw;&quot; statement do?

So i&#39;ve read all the lines from a file thusly

    while (getline(ifile,line))
        {
            // logic
        }

Where ifile is an ifstream and line is a string

My problem is I now want to use getline over again, and seem to be unable to return to the beginning of the file, as running

    cout &lt;&lt; getline(ifile,line);

Will return 0

I&#39;ve attempted to use:

    ifile.seekg (0, ios::beg);

To no avail, it seems to have no effect. How do I go back to the start of the file?

Returning to beginning of file after getline

This is almost exactly a duplicate of [Examining a single changeset in Mercurial][1], and without doubt a duplicate of another question I can&#39;t find on SO through Google alone. 

I&#39;m looking back through a Mercurial repo, and I want to see what exactly changed between two revisions (let&#39;s say 2580 and 2581):

    hg log -v -r 2581 

gives me all the **files** that changed.

How can I also see the **diffs** of these files?

Thanks.


  [1]: https://stackoverflow.com/questions/2550721/examining-a-single-changeset-in-mercurial

Mercurial: diffs in a particular changeset?

This is almost exactly a duplicate of <a href="https://stackoverflow.com/questions/2550721/examining-a-single-changeset-in-mercurial" target="_blank" rel="noopener noreferrer">Examining a single changeset in Mercurial</a>, and without doubt a duplicate of another question I can't find on SO through Google alone.
I'm looking back through a Mercurial repo, and I want to see what exactly changed between two revisions (let's say 2580 and 2581):
<pre><code class="hljs language-bash">hg log -v -r 2581 
</code></pre>
gives me all the files that changed.
How can I also see the diffs of these files?
Thanks.

What&#39;s the difference between a [tag][1] and a [bookmark][2] in Mercurial? I can&#39;t seem to find any discussion of how the two differ.


  [1]: https://www.mercurial-scm.org/wiki/Tag
  [2]: https://www.mercurial-scm.org/wiki/BookmarksExtension

what&#39;s the difference between hg tag and hg bookmark?

I am kind of new to both, Mercurial and Ubuntu.

I seem to have awkwardly installed a few other software packages already, so I wanted to see how others would go about doing this.

Should I use the apt-get command? If so, how would I use it in this case? Where is the best place to install Mercurial on my file system, and how do I make it part of my shell (I am thinking svn-ish) so I can properly check things in and update?

Thanks,
Alex

Correct way to install Mercurial on Ubuntu

I can see why distributed source control systems (DVCS - like Mercurial) make sense for open source projects.

But do they make sense for an enterprise? (over a centralized Source Control System such as TFS)

What features of a DVCS make it better or worse suited for an enterprise with many developers? (over a centralized system)

Distributed Version  Control Systems and the Enterprise - a Good mix?

Currently, I&#39;m moving from a legacy version control system and moving my group&#39;s project to mercurial.  As one example of the kinds of code I&#39;m moving, I have a 25+ project Visual Studio solution, containing several separate application areas that all depend on common code.  Looking over Stack Overflow, the closest question I found was [this one](https://stackoverflow.com/questions/647462/best-way-to-organize-dependant-projects), but it merely mentioned version control.  I&#39;m looking for a bit further advice, on specific implementation techniques of using Mercurial to manage these dependencies.

A simplified view of the dependencies look something like the following.  (This is for illustration and example only; the actual dependencies are significantly more complex but similar in nature.)

                         Common Lib 1
                        /      |      \
                    ----       |       -----   
                   /           |        \   \
                App 1    Common Lib 2    \ App 2
                           /   |   \      \
                    -------    |    ------ |
                   /           |          \|
                 App 3       App 4      App 5

The Common Lib modules would be shared code - this would be a DLL or SO or some other library that would be used between all the apps simultaneously - both at compile and run time.  Applications would otherwise be able to run independently from each other.

I have a couple goals with setting up my mercurial repositories:

* Give each significant application or component group its own repository.
* Make each repository self contained.
* Make the sum total of the project self contained.
* Make it easy to build the entire codebase at once.  (eventually, all these programs and libraries end up in a single installer.)
* Keep it simple.

One other point is that I have a server set up where I have separate repositories for each of these projects.

I see a couple ways of laying these projects out.

# 1. Create a &quot;Shell&quot; repository that contains everything.  

This would use url-based subrepos (eg, in the .hgsub, I&#39;d do something like &lt;code&gt;App1 = https://my.server/repo/app1&lt;/code&gt;.)  Laid out, it would look like the following:

    +---------------------------+
    | Main Repository           |
    | | +---------------------+ |
    | +-| Build               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| Common Lib 1        | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| Common Lib 2        | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 1               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 2               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 3               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 4               | |
    | | +---------------------+ |
    | | +---------------------+ |
    | +-| App 5               | |
    |   +---------------------+ |
    +---------------------------+

Each main folder in the shell repository would contain a subrepo, one for each project area.  Dependencies would be relative: Eg, since App 4 needs Common Lib 2, it would simply use relative paths to reference that common library.

Pros of this approach:

* Each library is pulled down once and only once.
* Mercurial&#39;s subreos will ensure that the same version of the library is used across all project automatically, since only one version of that subrepo exists in the project.
* It&#39;s easy to find each resource.

Cons of this approach:

* I can&#39;t work on an App independently.  Eg, if I work on App 2, and it needs a change to the common libraries, all of the other apps will have to take those changes right now.
* If I pull an App repo by itself, I have to figure out (or know) what other dependent repos it requires by hand if I want to build it.
* Dependencies are not strongly separated - it would be tempting to insert a new feature  anywhere since it was easy to get at all the features.

# 2. Have dependent subrepos be wholly contained.

In this approach, each application would have its own repository (as before) but this time also contain subrepositories: one for its own source, and one for each dependent subrepository.  An overall repository would then contain each of these project repositories, and know how to build the entire solution.  This would look like the following:

    +-----------------------------------------------------------------------+
    | Main Repository                                                       |
    | +--------------------+ +--------------------+ +--------------------+  |
    | | Build              | | Common Lib 1       | | Common Lib 2       |  |
    | +--------------------+ | | +--------------+ | | | +--------------+ |  |
    |                        | +-| Lib 1 Source | | | +-| Common Lib 1 | |  |
    |                        |   +--------------+ | | | +--------------+ |  |
    |                        |                    | | | +--------------+ |  |
    |                        |                    | | +-| Lib 2 Source | |  |
    |                        |                    | |   +--------------+ |  |
    |                        +--------------------+ +--------------------+  |
    | +--------------------+ +--------------------+ +---------------------+ |
    | | App 1              | | App 2              | |  App 3              | |
    | | | +--------------+ | | | +--------------+ | |  | +--------------+ | |
    | | +-| Common Lib 1 | | | +-| Common Lib 1 | | |  +-| Common Lib 2 | | |
    | | | +--------------+ | | | +--------------+ | |  | +--------------+ | |
    | | | +--------------+ | | | +--------------+ | |  | +--------------+ | |
    | | +-| App 1 Source | | | +-| App 2 Source | | |  +-| App 3 Source | | |
    | |   +--------------+ | |   +--------------+ | |    +--------------+ | |
    | +--------------------+ +--------------------+ +---------------------+ |
    | +--------------------+ +--------------------+                         |
    | | App 4              | | App 5              |                         |
    | | | +--------------+ | | | +--------------+ |                         |
    | | +-| Common Lib 2 | | | +-| Common Lib 1 | |                         |
    | | | +--------------+ | | | +--------------+ |                         |
    | | | +--------------+ | | | +--------------+ |                         |
    | | +-| App 4 Source | | | +-| Common Lib 2 | |                         |
    | |   +--------------+ | | | +--------------+ |                         |
    | +--------------------+ + | +--------------+ |                         |
    |                        | +-| App 5 Source | |                         |
    |                        |   +--------------+ |                         |
    |                        +--------------------+                         |
    +-----------------------------------------------------------------------+



Pros:

* Each application can be built by itself, independent of each other.
* Dependent versions of libraries can be tracked per-app, instead of globally.  It takes an explicit act of inserting a subrepo into the project to add a new dependency.

Cons:

* When doing the final build, each app might be using a different version of a shared library.  (might need to write tools to sync the common lib subrepos.  Eww.)
* If I want to build the entire source, I end up pulling down shared libraries multiple times.  In the case of Common Lib 1, I would have to pull it eight (!) times.

# 3.  Don&#39;t include dependencies at all as subrepos - bring them in as part of the build.

This approach would look much like approach 1, except the common libraries would only be pulled as part of the build.  Each app would know what repos it needed, and put them in the common location.

Pros:

* Each app could build by itself.
* Common libraries would only need to be pulled once.

Cons:

* We&#39;d have to keep track of versions of libraries currently used by each app.  This duplicates subrepo features.
* We&#39;d have to build an infrastructure to support this, which means more stuff going into build scripts.  Ugh.

# 4.  What else?

Is there another way of handling it?  A better way?  What ways have you tried and succeeded, what ways have you tried but hated?  I&#39;m currently leaning towards 1, but the lack of application independence, when it should be able to, really bothers me.  Is there a way to get the nice separation of method 2 without the massive duplicate code pull and dependency maintenance nightmare, while not having to write scripts to handle it (like in option 3)?

What&#39;s a good way to organize projects with shared dependencies in Mercurial?

I created a BitBucket account today, and I love the fact that they allow you to have unlimited public/private repositories. However, I didn&#39;t find the size limit of your account? Does anyone know where to find it? Github offered 300mb if I remember correctly.

Content Type	Original Author	Original Content on Stackoverflow
Question	AP257	View Question on Stackoverflow
Solution 1 - Mercurial	Ry4an Brase	View Answer on Stackoverflow
Solution 2 - Mercurial	vissi	View Answer on Stackoverflow
Solution 3 - Mercurial	thekostya	View Answer on Stackoverflow
Solution 4 - Mercurial	Adam Gent	View Answer on Stackoverflow

Mercurial: diffs in a particular changeset?

Mercurial Problem Overview

Mercurial Solutions

Solution 1 - Mercurial

Solution 2 - Mercurial

Solution 3 - Mercurial

Solution 4 - Mercurial

Returning to beginning of file after getline

What does a single "throw;" statement do?

Attributions