Can't commit any changes?

Thu Jan 13 05:17:58 CST 2011

Sounds great. Most important thing is that you have atleast some sort of 
version control up and running. It is fairly easy to convert Subversion 
repositories to Mercurial, if you give Mercurial another try at some 
point. I'm sure people will help with that incase you have problems.

From:   Ray Bartlett <rbartlett at 20miletech.com>
To:     mercurial at selenic.com
Date:   13.01.2011 00.03
Subject:        Re: Can't commit any changes?
Sent by:        mercurial-bounces at selenic.com

One of the developers got frustrated with the amount of time needed to
get Mercurial up and running and said it took all of 20 minutes to set
up a Subversion repo and have it working the way we wanted.  So I
guess this is moot, but thanks very much for the help.  Those of you
out there in the doc-writing world might want to think of people who
come to this totally fresh, who may not know the concepts and may not
have identical workflows...having a quick way to figure out on our own
what would work would have helped a lot.

In any case, we're going to Subversion, at least for now.  Many thanks
for the suggestions and taking the time to help.

On Wed, Jan 12, 2011 at 9:52 AM, Martin Geisler <mg at aragost.com> wrote:
> Ray Bartlett <rbartlett at 20miletech.com> writes:
>
>> [...] "To use Mercurial, you need three things: a repository, a
>> .hg/hgrc file, and a clone. The repository is the original source, the
>> clone is where the changes are made..." etc.
>
> Maybe the glossary will help you nail down the concepts:
>
>  http://selenic.com/hg/help/glossary
>
>> Take the http://mercurial.selenic.com/wiki/SharedSSH page, for
>> example.
>
> I'm afraid that is a bad example -- don't start with complex stuff like
> that. Mercurial and SSH is super easy assuming you are already familiar
> with SSH... and that page seems to assume that.
>
>> It's not a page that steps someone through the process of setting this
>> up. It's just a listing of different elements that relate to
>> SharedSSH. The same with many of the Tutorials I've seen. The quick
>> start, followed to the letter, didn't mention anything about setting
>> up a proper .hg/hgrc file, which is apparently vital. Then when
>> running Mercurial, I got an error (not mentioned in the Quick Start)
>> that turns out to be because I have to add a username to the .hg/hgrc
>> file (as in [ui] username = me <foo at foo.com>). But it still didn't
>> work.
>
> Okay, I agree that it's quite unfortunate that you get errors and output
> that differs to what the tutorial says. The guide I made here avoids
> that problem by double-checking all the examples when I upload the HTML
> files:
>
>  http://mercurial.aragost.com/kick-start/en/basic/
>
> The examples are most recently compiled with Mercurial 1.7.
>
>> Am I right to understand that without a line in the .hg/hgrc file
>> specifying a path, no changes will ever get back to the central repo?
>
> Almost... the key is that 'hg push' can take an argument on the command
> line. So you can do
>
>  hg push
>
> and Mercurial will then look in .hg/hgrc for a [paths] section and use
> the default path configured there. Or you can do
>
>  hg push http://server/my/repository
>
> and Mercurial will push there. See 'hg help paths' for some info.
>
>> And am I right to understand that while yes, Mercurial doesn't have a
>> "central" repo, since we need one, we can achieve something similar by
>> having people clone from and push to the same place, so that each time
>> someone's cloning it's always the latest version?
>
> Yes, exactly. Technically, there is no central repository, but in
> practise there always is by convention.
>
>> [...] On Thursday, it's a snow day, so people are at home. Person A
>> and B both decide to work on the same project, but thanks to our use
>> of Mercurial, this doesn't mean that Person B's changes are lost when
>> Person A pushes his work back to /var/www/html/lasersharks. Instead,
>> the changes of Person B and Person A get merged (presumably by "hg
>> merge" on the dev server?)
>
> Almost -- the merge is not done on the server, but instead done locally
> by the developer who pushes last. When Person A pushes, he will be told
>
>  $ hg push
>  pushing to /var/www/html/lasersharks
>  searching for changes
>  abort: push creates new remote heads on branch 'default'!
>  (you should pull and merge or use push -f to force)
>
> As Mercurial suggests, the right action is to do
>
>  $ hg pull
>  pulling from /var/www/html/lasersharks
>  searching for changes
>  adding changesets
>  adding manifests
>  adding file changes
>  added 1 changesets with 1 changes to 1 files (+1 heads)
>  (run 'hg heads' to see heads, 'hg merge' to merge)
>
> followed by
>
>  $ hg merge
>  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
>  (branch merge, don't forget to commit)
>
> and after a checking that things work, Person A commits the merge:
>
>  hg commit -m 'Merge with Person B.'
>
> This is described here (albeit in the other direction where Alice pulls
> instead of pushes):
>
>  
http://mercurial.aragost.com/kick-start/en/basic/#divergent-lines-of-development

>
> The screenshots there (should) show what is going on.
>
> After Person A has done the merge locally, he can now push to the
> central repository and Mercurial wont complain since he is no longer
> creating any new "heads" (see the glossary).
>
>> Again, I appreciate people's time.  Sorry if I sound down about this
>> -- as someone (maybe Mike?) suggested, once I'm up and running it will
>> all make more sense and be easier than I think.  But compared to so
>> many open source projects I've used, boy, the learning curve here has
>> been steeper than I expected.
>
> Don't worry, it will all fall into place... you are certainly right that
> the guides assume that the user already uses some other revision control
> system, frankly because that's how most developers work. So the guides
> focus on how to do things with Mercurial and maybe not as much on why
> you would want to do them -- they just assume you know why :)
>
> So yes, there is a lot of new concepts, especially if you start from
> scratch. Start with the basics: make a repository, make some commits,
> view the log. Then examine how you can clone the repository on your own
> machine and how you can push/pull between the two. When you have a good
> understanding of the basic commands, then move up to working with
> others. This is basically what my kick start guide tries to do :)
>
> --
> Martin Geisler
>
> aragost Trifork
> Professional Mercurial support
> http://aragost.com/en/services/mercurial/blog/
>
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20110113/a04c3efd/attachment.htm>