a bug with "hg update"

[Dustin Sallings]

   No, you're applying a CVS mentality to something that is not CVS.

   Make your changes, get it working, and commit before considering  
what other people may have done.  Otherwise, you can easily get lost  
in merges and lose the work you've been doing.

   update means set the working directory to a particular revision.   
That's often the latest in whatever branch you're working in, but not  
always. It is not a per-file operation.  Timestamps and names and all  
that do not matter.  It's just the state of the entire project at a  
given revision.

-- 
Dustin Sallings (mobile)

On Jan 21, 2008, at 6:56, Zhikai Cheng <zhikai.cheng at garmin.com> wrote:

> Thanks for help.
>
> On Sun, 2008-01-20 at 19:09 -0800, Dustin Sallings wrote:
>> On Jan 18, 2008, at 13:06, Zhikai Cheng wrote:
>>
>>> 1) I run the following command:
>>> hg mv file.1 file.2
>>>
>>> (file.1 is an existing file in the Mercurial repository.)
>>>
>>> Then, a new file file.2 was created as expected, and the file.1 was
>>> renamed as file.1.orig.
>>
>>    Not sure why there was a file.1.orig.  That doesn't make much  
>> sense
>> to me.
>>
>>> 2) before I tried to compile all my source code for testing
>>> I run the 1) hg pull and 2) hg update.
>>
>>    Did you not commit first?  If you didn't commit first, then you
>> shouldn't assume your changes will be in tact.
>
> If I did not commit the local changes into the repository. I run the  
> "hg update" to get the changes made by other developers.
> I d not think there is any problem. I plan to merge all changes,and  
> tested then commit my changes into the library.
>
> is this correct ?
>>
>>> 3) After step 2 I found that : the file.1.orig was renamed as file.1
>>
>>
>>    I would expect that.  update sets the tree to a particular  
>> recorded
>> state.  It probably *should* refuse to let you update in this
>> scenario, but you should probably just not do that in the first  
>> place.
>>
> I am not sure why you expect this. The files.1.orig has the time stamp
> which is  later than the time stamp of file.1. And they have two
> different names, file.1 and file.1.orig. It should not be replaced  
> based
> on the time stamp and names. That is why I said this is a bug.  and
> update means really up to date not BACK to date.
>
> the hg pull and update should not be refused in this step because it  
> is
> needed to get the latest changes other developer did on the same files
> and merge this changes into the local file, and test verify all of
> changes before commited and pushed into the repository.
>
> please let me know if there is any misunderstanding.
>
>
> -------------------------
> This e-mail and any attachments may contain confidential material  
> for the sole use of the intended recipient.  If you are not the  
> intended recipient, please be aware that any disclosure, copying,  
> distribution or use of this e-mail or any attachment is prohibited.   
> If you have received this e-mail in error, please contact the sender  
> and delete all copies.
> Thank you for your cooperation
>
>