Re: BRANCH LABEL FOR DIRECTORIES

[Greg A. Woods]

[[ I'm not going to get dragged into a stupid debate about comparing
apples and oranges in this silly filesystem analogy.  The only things
more pliable to one's needs than analogies are probably statistics.  You
can't prove anything with them -- they're only usefule as illustrations. ]]

[ On Monday, June 18, 2001 at 01:25:28 (-0700), Paul Sander wrote: ]
> Subject: Re: BRANCH LABEL FOR DIRECTORIES
>
> Okay, now consider this:
> 
> cp olddir/oldfile.c newdir/newfile.c
> cp olddir/oldfile2.c newdir/newfile2.c
> cvs rm -f olddir/*
> cvs add newdir/newfile.c newdir/newfile2.c
> cvs commit -m 'reorganized source to be better'
> cvs update -P
> 
> Guess what:  The old revision history is now hidden from the user.  To
> see the revision history of either of either file prior to the rename,
> he must figure out what tags (if any) have been applied to the files prior
> to the rename, use one of them to check out the module, and bounce back
> and forth between the two workspaces to see everything.

However I can't let that sit.  What a downright stupid and misleading
example.  Paul you can continue to manufacture stupid scenarios to try
to prove your point of view, but nobody's buying it.

Yes the documentation should be improved so that users have no excuse
for doing that kind of nonsense.

Luckily such mistakes can be easily corrected after the fact (at least
within the timeframe of the committer's memory).

> Except that in CVS the revision history does not remain in place; a new
> RCS file has been created, and it is modified from that time forward
> while the old one is ignored.

You're looking under the hood again -- I thought I told you not to do
that!  Use your imagination!  Pretend all combinations and permutations
of RCS files exist all the time.

> In that case, your requirements are really simpler than most.

Don't try to tell me what I'm doing -- you're not sitting here watching
me day in and day out and you have no access to my past and present
projects.

> Yeah, you replaced renames with repeatedly re-importing your sources
> into clean modules, right?

No!  You're not paying attention and your making incorrect assumptions.

> I worked on the Unix System V (both the definitive and the Solaris variants)
> for four years, and in that time I experienced no fewer than two significant
> reorganizations in each, all fed from offsite.  The teams I worked with
> required the complete version history of every file to be immediately
> accessible from their workspaces so that they could use "cvs log" and "cvs
> update -j" without thinking about how to find the same file in some other
> place that it occupied prior to a reorg.  Not having that capability was a
> tremendous hardship.

You must live with the circumstances you create for yourself.  Sounds
like so much disjoint change was introduced without planning that it
took more effort to try and manage the result after the fact than proper
planning ahead of time would have taken.  Yes code maintenance is
sometimes "hard", but it doesn't have to be a "tremendous hardship" no
matter what tools you have to work with (even if it's just pencils and
graph paper!).

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>