script suggestions

[mp3geek]

the loss commits got to my other user, so he created a script to clone
everytime, which seems excessive, I just want smooth way of sync'ing and
pushing out any changes, or do I need 2 scripts ?

On Sat, Jan 23, 2010 at 9:41 PM, mp3geek <mp3geek at gmail.com> wrote:

> okay slight modification, so is the order the script okay?
>
> #!/bin/bash
> hg update
> hg pull --rebase remote
> hg pull
> hg add .
>
> hg commit -m "$1"
> hg push
>
> If both users (2) use this script, I won't get lost commits, any data loss
> sucks or "mixups"
>
>
> On Sat, Jan 23, 2010 at 9:17 PM, Giorgos Keramidas <
> keramida at ceid.upatras.gr> wrote:
>
>> On Sat, 23 Jan 2010 17:27:03 +1300, mp3geek <mp3geek at gmail.com> wrote:
>> > Seems if I use hg pull --rebase, I still have to do hg pull to
>> > actually pull any new changes
>>
>> Not really, no.  You shouldn't need multiple pulls for rebase to work --
>> unless, of course, someone else pushes *more* changes between the time
>> of your first pull and your second pull.
>>
>> I often rebase my work at the repositories of my dayjob, and all it
>> takes to really keep the changes on top of the latest tip (whatever that
>> happens to be) is to run:
>>
>>    $ hg pull --rebase remote
>>    [ rebase and merge my local stuff ]
>>    $ hg push
>>
>> If the "hg push" command reports that it would create a new head I just
>> lost a race.  Someone else has pushed more changes to the 'remote' tree,
>> so I re-rebase:
>>
>>    $ hg pull --rebase remote
>>    $ hg push
>>
>> Fortunately, we are a small team and there tend to be a really small
>> number of races between a pull-and-rebase step and a subsequent push.
>>
>> > anyways, the script sort of works..
>> >
>> > #!/bin/bash
>> > hg pull --rebase
>> > hg add .
>> > hg update
>> > hg pull
>> > hg update
>> > hg commit -m "$1"
>> > hg push
>> >
>> > user at home-desktop:~$ ./script.sh "sample commit"
>> >
>> > However I've come accross when I tried to commit a new change, to then
>> > reverse another users commit, which I'd like to avoid happening.
>>
>> This is often a local merge problem.  It is one of the reasons why I
>> usually recommend running a smart 3-way merge tools (like ediff-mode of
>> Emacs, vimdiff or kdiff3, meld, etc) and *carefully* looking at _all_
>> the rebased changesets before pushing back.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial/attachments/20100123/2a77947e/attachment.htm>