Can't commit any changes?

Tue Jan 11 18:12:00 CST 2011

Ray,

I totally agree with Michael -- give this a chance, you will not be sorry.
 I can't live without Mercurial (the first thing I do when setting up a new
linux box is:  cd /etc; hg init....).

Since you appear to have developers developing a web-page, I'll give you a
few more pointers for configuration as you ramp up.  These are details I
expect you'll need later, though maybe not at right now.

1)  I would set up ssh as the method for developers to push back to your
repo:  http://mercurial.selenic.com/wiki/SharedSSH.  I would setup a global
user/password that everybody uses.

2)  *On the server*, you want to setup a hook for updating the website after
each push.  For development sites (I remove this after going into
production), I add the following lines to .hg/hgrc (this was a symfony
project, and I wanted to clear the cache after each push):

$ cat .hg/hgrc
[hooks]
changegroup.update = hg update; ./symfony cc

3)  (This is something I've been forced to do, YMMV)  *On each developer's
machine*, they each should edit their .hg/hgrc and setup their username for
the push:

[ui]
username = "YOUR NAME" <YOU at YOUREMAIL.COM>
[paths]
default = ssh://USERNAME@SERVER//var/www/html

Mike

On Tue, Jan 11, 2011 at 6:50 PM, Michael Diamond <dimo414 at gmail.com> wrote:

> On Tue, Jan 11, 2011 at 3:16 PM, Ray Bartlett <rbartlett at 20miletech.com>wrote:
>
>> Gosh, Mike, thanks for taking the time to write.  I had already found
>> that page but clearly my definition of "simple" isn't at all matching
>> the Mercurial concept.  In the "quick start" I saw that you clone via
>> http...didn't realize that didn't allow for the full circle to happen.
>>
>
> Basically, Mercurial is really easy and painless for developers who are
> using it.  Unfortunately, as is true of most things, there's a little more
> work on the operations side of things :P  Having configured a couple of
> different Mercurial repositories I can say it's not /all that/ bad, but it's
> still a bit of work.
>
>>
>> Really, I need a simple step by step walk-through (if there is such a
>> thing) for setting up a repository that people can write and read to.
>> I'm not sure why it matters whether it's /usr/var/www/html or
>> /some/other/directory.  Users are hoping to use a Mac client called Hg
>> (a gui) to do most of the work.
>>
>> How exactly does one return a cloned repo back to the pool so others
>> can find it, access it, and make new changes?
>>
>
> Look through the publishing repositories Wiki page Mike linked you to,
> you're on the right track you just need to do some server configuration.
>  The basic gist is you put a copy of the repository (we'll call this the
> central repository) on a web server (though not in root, generally
> speaking).  Then you configure Apache to serve up access to the repository
> so that authorized users can clone it, and also push to it.  The details are
> in the wiki.  It sounds like you /also/ want people to be able to see the
> build in a live web server immediately.  In that case, you either want the
> development web server to pull the changes from the central repository
> every, say, thirty minutes, or have a hook (look in the wiki for info on
> hooks) in the central repository that pushes all changes on to the
> development web server.
>
>>
>> In our case, our developers want to be able to quickly and immediately
>> see how the changes look on the web, hence the need to publish to the
>> /var/www/html directory.
>
>
> This still will only show changes once the user *pushe*s their changes
> from their local machine to the central repository, not immediately.
>  Generally speaking - and this is good practice in general, not just with
> Mercurial - developers should be able to do as much reviewing and testing as
> they can locally, before they share their changes with everyone else.  This
> might involve having a small web server running on each developer's
> computer, for instance, and ought to resolve the problem of needing to see
> the changes "on the web" instantly.  If not, you may want to look more
> deeply at your development process.
>
>>
>> Is there a syntax so that instead of "publishing by http" they can
>> publish some other fashion?  Does Mercurial usually require people be
>> on the same local machine?  If so, it seems kind of impractical.
>>
>
> There are several different ways to publish (see the wiki article Mike
> linked again) and Mercurial not only does not require people be on the same
> machine, it is in fact designed around the principle that they are on
> completely different machines that are not connected.
>
>>
>> Again, thank you for the help.  I guess coming from a mindset of FTP
>> or so on, I feel like it should be a relatively easy thing to use
>> Mercurial over a intranet or the internet.  I need people to be able
>> to be home and still able to clone, make changes, and return their
>> files back to the pool.
>
> An excellent introduction to the mindset of Mercurial and DVCS is
> http://hginit.com/ - this may help you wrap your head around some of the
> differences between something like FTP and Mercurial.  Speaking as someone
> who used to use FTP like it sounds like you do, Mercurial is a /vast/
> improvement, but it is different, and takes a little getting used to.  Where
> the person is when they are cloning is entirely dependent on your server
> setup.  If you create a central repository that is world readable (like
> http://mercurial.selenic.com/hg) then anyone anywhere can read it, and
> anyone with permission can push to it.  If, on the other hand, you lock your
> server down more so that only certain people or places can access it, then
> of course only those people and places can get to the repository.
>
>
>> Am I just barking up the wrong tree entirely?  Is this what Mercurial
>> does?  Or should I investigate other version control options?  Or just
>> tell people they need the command line and they have to ssh directly
>> into the /var/www/html directory to do any work?
>>
>
> Mercurial does a fantastic job of exactly what you're describing, promise!
>  There is no such thing however as version control that just falls into
> place magically.  It will involve design, development, and workflow changes,
> and time setting up.  These changes will all be for the better in the long
> run though!
>
> Michael Diamond
> dimo414 at gmail.com
> www.DigitalGemstones.com <http://www.digitalgemstones.com/>
>
> _______________________________________________
> 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/20110111/ca4d79c6/attachment.htm>