|
From: <gor...@bl...> - 2002-05-13 20:04:27
|
Hi guys!
Quoting Bert Freudenberg <be...@is...>:
> On Mon, 13 May 2002, Tim Rowledge wrote:
> > > The update will tell you what files are modified "M"
and that will
> be
> > > committed.
> > > You can also then see if other people have just committed stuff
> ("P"/"U"
> > > etc) that you should take into account before committing.
> > Ooh, ooh, does P mean 'pending'? I saw it a few times the other day
> > (when I managed to commit everybody's open files - I cn't imagine
> what
> > the logical argument in favour of that working was) and couldn't find
> an
> > explanation in any of my cvs doc (I have assorted webpages snarfed
> > locally that I use).
>
> Then you just don't use the right doc. It's mentioned in the info files
> as
> well as here, for example:
> http://www.cvshome.org/docs/manual/cvs_16.html#SEC154
>
> U The file was brought up to date with respect to the repository.
> P Like `U', but the CVS server sends a patch instead of an entire file
> M The file is modified in your working directory.X
> C A conflict was detected while trying to merge your changes
>
> -- Bert
Yes, a "U" is FULLY equivalent to a "P" - it means that your workingcopy was
just updated because someone has committed a new version of the file since you
last updated it. "M" means that the file in question has a local modification in
your working copy and if you commit it a new revision will be created for it.
Interestingly a file marked "M" could very well have been updated during the
update and automerged without conflict. You would have to study the output to
discover that actually - I don't think you can see that otherwise. A bit dumb.
Anyway - if you have made a change, compiled, tested and everything is dandy and
then you do an update right before commit - IF you then get U/Ps then you should
recompile/test again IMHO and perhaps study what came in.
Otherwise you run the risk of committing something that won't build. If the
update comes out clean then go ahead, nothing has changed since you last updated
so everything must be OK.
A nice sideeffect with running the update before commit is that you also see the
Ms and based on that you can more easily decide what to write in the commit
comment. It is quite common that you think you have only fixed bug X and when
you do the update you realize that, hey, I almost forgot - I also edited file Z
to fix that little buglet Y...
regards, Göran
PS. I am actually adding support for "P" in sqcvs - the CVS protocol
is capability based and if the client says "Nope, I can't handle patch
files" then those don't get sent by the server- no "P"s shows up. But that is a
good thing to be able to handle so I just added it actually... :-) The unified
diff is very easy to apply. DS
Göran Hultgren, gor...@bl...
GSM: +46 70 3933950, http://www.bluefish.se
\"Department of Redundancy department.\" -- ThinkGeek
|