<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I look before and after, fyi, not just after, and do strive for coherence, within the limits of CVS (I think it's still only one file at a time, rapidly, one right after the other). Thanks for the other tips. cvs diff seems so inefficient. SVN's double diskspace is definitely worthwhile vs. CVS, but the way it should REALLY work is have the files be initially read only on the client, make me "check them out", which would save a copy and save some state locally as to what is checked out. No cooperation with others should be needed here. Perforce does this all correctly.. it seems pretty obvious and simple how to impelement this well. Ok, actually Perforce doesn't save the local copy. But it does know what you checked out, so it only goes to the server for the small number of files. So nobody gets it quite right, that I know, that I have used, yet, really, it seems so obvious and simple and inefficient and convenient......<BR><BR> sorry about the annoying ad, it's not my doing <BR><BR>
<HR id=stopSpelling>
> Date: Wed, 2 Jan 2008 12:21:48 +0100<BR>> To: jayk123@hotmail.com<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] cvs question: how to know what I have changed on my machine?<BR>> From: wagner@elegosoft.com<BR>> <BR>> On Mon, Dec 31, 2007 at 09:48:26AM +0000, Jay wrote:<BR>> > <BR>> > I swear I looked for this on the web, several times. :)<BR>> > What is the right/fast way to see what I have changed in cvs?<BR>> > Is it really to go to the top of the tree and say cvs diff?<BR>> > Some source control system I have used, makes "checked in" files<BR>> > read only, requires you to "check out", and keeps track of what<BR>> > you checked out.<BR>> > This model seems quite nice.<BR>> <BR>> cvs works recursively from the current directory by default.<BR>> To check what has changed you use<BR>> <BR>> cvs -nq up<BR>> <BR>> which simulates an update and lets you know the status of changes.<BR>> <BR>> To get more details, you use<BR>> <BR>> cvs -q diff -u [files] | less<BR>> <BR>> This is of course what I do most of the times. There may be other<BR>> ways.<BR>> <BR>> > There is a fallback if the network is needed and not available.<BR>> > It is a little annoying, the inevitable failed save, but it is well<BR>> > worth it.<BR>> <BR>> CVS use an optimistic approach wrt. locking, and it works well in<BR>> practice. Locks or watches can be set if one really wants to, but<BR>> this needs the cooperation of all users. See `cvs edit' and<BR>> `cvs watchers' for details.<BR>> <BR>> > I've been doing cvs diff but it seem terribly inefficient.<BR>> > Same question for Subversion, though I haven't looked.<BR>> > It at least seems to rapidly know what I have changed, on my puny<BR>> > tree,<BR>> > and I know it also saves away all the originals, so diff is a client<BR>> > only operation.<BR>> <BR>> In Subversion, diff is a client operation wrt. the base vesion you<BR>> checked out, because that is held as backup copy in your workspace.<BR>> This leads to workspaces which occupy twice the amount of space,<BR>> but is sometimes worth the effort.<BR>> <BR>> > Oh another question -- how to view history?<BR>> <BR>> In CVS, the history for one file is called log. Use `cvs log file' to<BR>> view it. To get a complete history of changes, use the cvs2cl<BR>> utility, which accumulates changes recursively into ChangeLog files.<BR>> It's what you can see at http://modula3.elegosoft.com/cm3/ChangeLog<BR>> for the cm3 repository.<BR>> <BR>> > Like, what i keep doing is navigating to individual files on the web.<BR>> > It's fairly tedious.<BR>> > It'd be nice if checkins at right about the same time, with the same<BR>> > comment,<BR>> > where packaged up in the ui, like Perforce (well, for it, it is just<BR>> > one change)....<BR>> > I usually look at the diffs after commit, besides before.<BR>> <BR>> I'd suggest to do commits at package level (to always have a<BR>> consistent version checked-in) and look at the diffs before commit.<BR>> There are some more suggestions in <BR>> <BR>> http://modula3.elegosoft.com/cm3/cm3-cm-rules.html<BR>> <BR>> Olaf<BR>> > Thanks,<BR>> > - Jay<BR>> <BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR><br /><hr />Share life as it happens with the new Windows Live. <a href='http://www.windowslive.com/share.html?ocid=TXT_TAGHM_Wave2_sharelife_122007' target='_new'>Share now!</a></body>
</html>