Can't commit any changes?

Tue Jan 11 23:08:35 CST 2011

You should start out with Subversion. Then on the webserver, just do an 'svn sync' to a tag or HEAD once you've got everything checked-in that you want to release.

- Rene

--- On Wed, 12/1/11, Ray Bartlett <rbartlett at 20miletech.com> wrote:

> From: Ray Bartlett <rbartlett at 20miletech.com>
> Subject: Re: Can't commit any changes?
> To: Mercurial at selenic.com
> Received: Wednesday, 12 January, 2011, 12:01 AM
> 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
> >
> >
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
> 