what do I need to learn to do this task?

[Justinas Urbanavicius]

Dave, i completely agree with your that you shouldn't wait for
release-ready to do a commit, you should commit "as often as natural breaks
occur", but you shouldn't use commit more often instead of save.
Once i had a colleague that commited and pushed frantically, i observed him
once, he found a bug, so he tried one fix, commited, then pushed, it didn't
work, then he tried another fix, commited and pushed,
and it annoyed the crap out of everyone :) eventually we taught him that
you should commit once you have fixed the bug, but not after each try :)


On Tue, May 13, 2014 at 9:18 AM, Dave S <snidely.too at gmail.com> wrote:

>
> On May 12, 2014 11:08 PM, "Justinas Urbanavicius" <justinasu at gmail.com>
> wrote:
> >
> > well each of repository is already a backup by itself,
>
> That's true from a changeset perspective, but not from a crash perspective.
>
> > and i don't think you have to learn anything special. hg serve command
> shows you what ip/host your server is running on so you just need to write
> it into your config.
> >
> > either way i think you are using mercurial as a backup tool more than a
> version control, some people like to do commits, paranoiacally as often as
> using save in word :)
> > but i don't think it's a good practice, each commit should be
> meaningful, a change that reflects something
>
> And I vote for the middle ground.  Don't wait for "release-ready"; do
> commit at least as often as natural breaks occur.  From the point of view
> of being able to unwind mistakes, more ci beats less ci.
>
> /dps
>
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>
>


-- 
Justinas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140513/a63ca8ea/attachment-0002.html>