[p4] Unwanted new timestamps after submit
Noel.Yap at morganstanley.com
Wed Dec 8 11:45:40 PST 2004
I'm not sure if this'll solve the OP's problem or if anyone has mentioned it, but will the modtime option in the client help?
Kevin Wang wrote:
> On Wed, 8 Dec 2004 11:20:43 -0600, chris.bartz at ni.com
> <chris.bartz at ni.com> wrote:
>>I never said it should guess and then stick with its guess even if it is
>>wrong. I suggested doing 2 things; check if the file changed and only
>>update the clients file if it does, and fill in the keywords at
>>It should still update the keywords at submit but by doing the first thing
>>it would not update the file if its initial guesses were correct. This
>>isn't perfect but it does help for many normal usages.
>>Obviously, it doesn't know DateTime before you submit (and change will
>>most likely be wrong) so if you use those keywords you still have this
>>problem. But it does know author, revision, and file.
>>If I open a file for edit (or integrate), it can set the revision to 1
>>higher than the current head. If someone submits changes before I submit
>>mine then I will have to resolve the conflicts and rebuild anyway. It can
>>put in the new head+1 revision number as part of the resolve. The
>>revision number is again correct while I am building and testing. When my
>>submit eventually succeeds (i.e. there are no conflicts), the revision
>>number will be correct.
> I completely disagree. consider what happens if you:
> p4 edit file (revision number updated)
> you do a build and accidentally or purposely release it
> you sync/resolve because someone else submitted a revision to the file
> before you did... now your id string is wrong!
> It's fundamentally flawed and won't work.
> - Kevin
>>>From: arnt at gulbrandsen.priv.no [mailto:arnt at gulbrandsen.priv.no]
>>>Sent: Wednesday, December 08, 2004 10:49 AM
>>>To: perforce-user at perforce.com
>>>Cc: Max.Ritter at brainlab.com; Noel.Yap at morganstanley.com;
>>>Chris Bartz; robert at vaccaperna.co.uk
>>>Subject: Re: [p4] Unwanted new timestamps after submit
>>>chris.bartz at ni.com writes:
>>>>Second, it should attempt to fill in the keywords when you
>>>open a file
>>>>for edit (and when you resolve conflicts). It could certainly get
>>>>Author, revision, and file right at that time. This would
>>>give you the
>>>>added benefit that you are building the same thing that
>>>You mean that when doing integrate, perforce should guess
>>>which change/revision number the file will eventually be submitted as?
>>>If someone else is also submitting things, that sounds rather
>>>Perforce's bound to get it wrong, and then you have
>>>$Revision$ numbers that have no relation to either the old or
>>>the new version of the file in question.
>>perforce-user mailing list - perforce-user at perforce.com
More information about the perforce-user