Re: Question about version numbers.

[stremler]

Greg A. Woods <address@hidden> wrote:
[snip]
> That suggests there's something lacking in how your users make use of
> branches.

> The best way to work with branches is to ensure the name of the top
> directory you create to check out a branch should include both the
> module name and the branch name.  I don't know if it's documented
> anywhere, but I always thought it was self-obvious. 

Heh. So I'm not so off-track. This is basically what I have ended up
doing, and have recommended to others...

>                                                      For example:
>
>       cvs co -r FOO-BRanch -d mymodule.foo-br mymodule

Let's say the project/contract is FOO. The branches are 'bar' and 'baz',
with my primary interest in the 'bar' branch. [Also assume *nix -- the
developers who have the most trouble are using NT, exclusively. Figures.]
The top-level module is QUX. I might set up a clean checkout in this way:

% mkdir FOO
% cd FOO
% mkdir Bar
% mkdir Baz
% mkdir Main
% cd Bar ; cvs checkout -r bar_branch QUX
% cd ../Baz ; cvs checkout -r baz_branch QUX
% cd ../Main ; cvs checkout QUX
% cd ../..
% ln -s FOO/Bar/QUX QUX

(The link is for convenince with classpaths; and a "cd ~/QUX; pwd" should
put me in the 'right' place with enough information to tell me that I'm
in the right branch. Getting confused about which checked out tree I'm
in hasn't been a problem...)

> Then all it takes is a 'pwd' to find out what branch and module you're
> working on at any given time (or maybe you even have your pwd in your
> window title as I do...).

As often as I can.  :)   I use tcsh's cwdcmd facility to set it.

> I do know that the documentation recommends using "cvs update -A" to
> convert an existing working directory from one branch to another.  I've
> always recommended rather strongly against doing this because it is very
> easy to make a mistake when doing it.

I avoid "update -A". I'm not /trying/ to corrupt the tree...

>                                        Always use "cvs release -d" if
> you want to get rid of an old working directory and then check out a new
> working directory from scratch.  If this is too time consuming then your
> modules are too big (or your filesystems are too slow :-).

Generally, I don't have much that /isn't/ in the tree. I commit early
and often.  I'll check in files of dubious value, and use "cvs rm -f"
when I no longer need 'em.

Assuming that all the stuff I want checked in *is* checked in, how is
"cvs release -d" better than "rm -rf"?

/me goes and checks the manpage.

Ah, it leaves an entry in the history file, too. Why would that be
useful, in a small shop?

>> or CVS gets confused and we get mixed branches and/or sticky-tags that
>> provides all sorts of fun with inconsistent state.
>
> I can't even begin to imagine how that could happen.....  (except
> perhaps if you use "cvs update -A" incorrectly)

Neither can I, but it has happened to me.  And the novice developers who
aren't comfortable with CVS probably don't know about "cvs update -A".

>> Stuff that would
>> stand out if, embedded in the file, was the last-set tag and the delta.
>
> Embedding versioning information in unfrozen files is far more likely to
> cause errors!

Why?

(I'm honestly not comprehending what sort of errors it could cause.)

> If I had my way I'd have decreed that CVS never expand any keywords in
> the working directories, just as SCCS does.  There was, IIRC, even a
> short period of time back before the release of 1.4 where this was even
> considered to be a default mode of operation, but too many people were
> too accustomed to using RCS for it to be accepted.

Hm. I did start with RCS before CVS, and have never been subject to SCCS.
It probably influences my thinking...

I *like* repository state information in my source files. It /helps/.

> Of course you can do this anyway, but I'm too lazy to do it, and I'm
> sure enough of my own development process that I don't expect I'll ever
> make any mistake[*].  The way you'd do this is set a "sticky" -kk option
> on checkout by putting the following in your ~/.cvsrc:
>
>       co -kk -d -P

I used -kk once when preparing for a merge. It was a horrible experience.

> [*] I'm sure of my process because I've actually implemented checks to
> ensure that I don't screw up!  ;-)   My commitinfo calls a script that
> verifies there is a $Id line near the top of every file and then
> validates the revision number in that file matches the expected ancestor
> revision for the file (if the file is _not_ in a vendor-branched
> module).  In the end I think it gets in the way far more often than it
> helps though.  I also do a majority of my CVS use with vendor branched
> modules, which means I check them out with '-ko' and never put my own
> locally expanded keywords in the locally modified files.

I've not customised the basic CVS environment like this at all. Should I?

> Hmmm.... maybe I'll start using 'cvs co -kk' on my locally mastered
> projects and just get rid of that silly $Id validation crap.....

...apparently not. :)

[snip]
>> But I don't work with frozen releases. I make 'em, export 'em, and then
>> move on. 
>
> But that's the whole point.  You're supposed to export a release
> (i.e. freeze it), before you do anything with it outside of a working
> directory where you've got full access to its current state and history!

My cvs repository isn't local. And I'm not running a pserver; remote
access is strictly via ssh.  Using cvs commands to inspect the status
of a file just clutters my desktop, takes more time, and depending on
where I'm at (say, on a novice's machine trying to figure out what's
trashed on their system), lots of keyboard shuffling for password and
passphrase typing.

Going to the shell to find out the current state doesn't strike me as
being a very good process; it breaks continuity, often requiring me 
to grab the mouse or otherwise shift my focus away from the file at
hand -- which seem to be prime candidates for errors and misinterpretations.

(Now, if I were using emacs, or a CVS-aware IDE, I might be able to 
acquire status and state information without this sort of problem,
but emacs hurts my wrists, and IDEs tend to be mouse-driven, so 
neither one are options....)

> Just make sure you use 'cvs export -kv' to really freeze the keyword
> values permanently.

Hm. Good point.

> Do not ever copy any files (source or product) from a working directory
> and use them for anything where they might be confused with any files
> from any other working directory!

[snip]

> Don't use paper!  Seriously!  Always work online in the relevant working
> directory!  If someone really needs paper to work with then they can use
> it, but they must only use it privately and never share it.  Paper has
> no history or state w.r.t. the repository!

Not using paper? Heresy!

Seriously, paper is extremely useful for me. It travels better than 
laptops, is easier to read and debug as source [I'm assuming that 
debugging-on-paper means that debugging-by-running has already failed.],
to understand as an algorithm...  The CRT is a low-resolution display.

I've been told about the paperless office and the paperless development
process for fifteen years, and I still haven't seen it.  :-/

Granted, I generally work online, but I may have a dozen files in the
buffer of the editor, and four to six xterms on the current desktop,
but "current directory" doesn't match to a file being currently edited. 

(I don't copy files. But I do print 'em out... especially if it's a 
code problem with someone else's code, and they're on a NT box. I
can't get work done under NT, and checking it in would break other
stuff, so paper is a good alternative.)

>> (Or if I sit down at their machine, and start looking
>> at what they're working with. Since it's not my machine or account, 
>> using the cvs commands to investigate isn't practical.)
>
> Don't use their account (or their machine)!  Login as yourself.  That
> way you won't accidentally change anything in their directory either.

I don't have accounts on their machines. And they're having problems
in THEIR repository.

Typically, when I'm approached with a problem like this, it's where's
your code, and what branch is it in? Then I go there in my copy, make
sure I have an up-to-date version of everything, and lo! It works for
me.

That doesn't help me to help them...


[snip]
>> It Has Been Declared That Revision ID Numbers Are Not Meant For Humans.
>
> You misunderstand.  Read the rest of the sentence again:
>
>> > from there you can always deduce everything else that's relevant by
>> > using them as an index into the "cvs log" output for the given file.
>
> Revision Ids are simply indexes into the repository.  Use them only for
> that purpose.

That's what computers are for. Going around trying to match up opaque
numbers is worse than adopting a scheme that gives meaning to those
numbers and updating them every time a tag is made.

THAT worked, but isn't kosher.

(Before that, using $Log$ in the file indicated what was going on, which
worked, but it tended to make the files large, and again, it isn't kosher.)

>> Deducing everything that's relevent through five minutes of using
>> cvs status and cvs log is four minutes and fifty-five seconds of
>> wasted time.  I'm certainly not going to be able to make that fly
>> with a developer who still isn't comfortable with 'cvs commit'.
>
> You're not making effective use of your tools!  :-)

:-P

I'm not allowed to use pointed sticks for motivational purposes.

Oh, wait, _my_ tools. That would be xterm, gvim, cvs, find, grep, awk...

> (oh, and don't forget 'cvs annotate', or it's equivalent in PCL-CVS,
> etc. either -- it's very very very useful!)

Hm. Yes, but it'll take some practice to properly interpret and use
effectively. 

How often do you use annotate? Daily? Before you start changing any code?
Only when there's a problem?

[snip]
>> Alas, that's not the case.
>
> Why not?  You should be able to define a proper and appropriate and
> consistent software development process that makes use of CVS for
> version control.  Many others have.  :-)

I'm not management.

-- 
   Stewart Stremler                                 address@hidden
 -----------------------------------------------------------------------------
                Most people's names are Welsh in ROT13.
                                      -- Peter da Silva (March 2000)