Can't commit any changes?

Tue Jan 11 23:01:06 CST 2011

Well, thanks to EVERYONE who has taken time to write and point me in
the Mercurial direction.  I think one part that I may have not gotten
is what's described below:  the [path] has to be set or else the push
doesn't go anywhere.  Am I right about that?

Now maybe if I describe the workflow more, someone will agree that
Mercurial is indeed the right tool for this.  What worries me is that
someone said that Mercurial only records info about the
changes...either I didn't understand that comment correctly or, yes,
Mercurial version control is not what I'm looking for.

1.  We're a small company with half a dozen employees all in pretty
good communication with each other.
2.  We build websites, but often we develop on an internal server.
Altering files isn't so complicated, but when websites depend on
databases, it's much more complex to have totally separate dev systems
on each users notebook because merging the files later is tricky and
merging radically different databases is much harder.  What we need is
for the most recent version of whatever has been worked on to be
what's visible on the internal web server (not a live server on the
internet).  Am I wrong to think that just pushing to /var/www/html/ is
the way to go?  It seems...well, I guess I may still not understand
the process, but it just seems like having a separate directory
somewhere else just creates more work.  Someone clones the project,
works on it, pushes it back to the original location...someone else
clones it, works on it....wash, rinse, repeat, wash rinse repeat.  No?
3.  Once we've completed a site, it will be taken off the dev server
and moved to the real world and any future changes will be tweaks done
by FTP.  So we're not talking a hook that's updating the real website.

I am grateful that so many people out there have offered LOTS of
suggestions.  My problem might be as simple as incorrect .hg/hgrc
files.  But the below (from Mike) seems like the closest to what I had
in mind...so I'll probably go this route.  However, wouldn't having a
global user/password mean all the revisions show up as the same
person?  Currently, people ssh in via their own unique login and
password.

Again, THANK YOU for taking the time to make suggestions and help
guide me through this.  I wish I wasn't such a bozo at this, but
everyone starts sometime.  The documentation (I've read through lots
of it) seems more esoteric than what I'm ready for.  Basically, I just
need to have a "type this, then this, then that" at the command
line...the below is a great start.

On Tue, Jan 11, 2011 at 7:12 PM, Mike Crowe <drmikecrowe at gmail.com> wrote:
> 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 pushes 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
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
>>
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>