Re: BRANCH LABEL FOR DIRECTORIES

2001-06-19 Thread Ralph Mack

 Greg's comments generally fall under the That's by design category 
 but it's not obvious that that design is good.

Every team needs someone who is passionate about protecting the elegance 
of the original design and not succumbing to creaping-feeturitis. For this 
reason, I'm very, very glad that Greg is here. 

However, I do tend toward the notion that a revision control system
should automatically track important events in the lives (plural, 
given branching) of every file it contains, including merges, moves, 
and renames. Not supporting these affects the continuity of the history,
which in turn affects automated operations like subsequent merges.

 I've been working lately with a SCM tool that versions directories and
 I've found that it makes life much easier (at least with regards to 
 renames and branching).
 
If it is possible to truly track directory changes by inference from 
file changes, I'm all for it. Directory tracking is problematic in a 
variety of ways, as it is in some sense a second view of some of the
same data. I suspect that the imperfections in directory tracking 
you've experienced may a side-effect of imperfections in tracking file 
movement and renaming. If these are done correctly, it should be possible 
to infer directory behavior from them. 

The two directory changes that I can think of that can't be inferred 
from properly tracked file activity are creation and deletion; the only
effect of this is that an empty directory is indistinguishable from an
absent one. I think accurately tracking the existence of empty directories 
is the least of CVS's limitations, so I'm willing to let that one go. 

Ralph A. Mack


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: BRANCH LABEL FOR DIRECTORIES

2001-06-19 Thread Ralph Mack

 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

 However I can't let that sit.  What a downright stupid and misleading
 example.  

This doesn't seem like a manufactured scenario to me - more like something
that comes up every so often, although I'll admit it has fewer files than 
the normal case. It looks like what I would do if you had to move the 
contents of a directory from one place in the directory tree to another? 
How would you do it, Greg? 

It isn't enough to say that you simply wouldn't let this happen to you.
Migrations, even mass migrations, are a fact of life; demands of logistics
often place their prevention beyond our control; since they cannot be 
prevented, they need to be supported without damaging continuity.

 CVS isn't a market driven product -- it's a freeware niche product.

I don't see CVS as a niche product at all. CVS is as mainstream as Linux
or Java. Most of what most people need is easy to learn and use, with 
the exception of branches and merges. Set up is kind of fragmentary, as
for many Linux services, but it seems to have all the right hooks in all 
the right places for integration into corporate build mechanisms. Its
support for Windows clients is adequate. As companies become more 
accustomed to shareware, I could see it become the preferred version 
control system for corporate Unix/Linux. If the Windows version could 
register out of the box as a Win2000 service, I could see it becoming 
popular for Windows shops, too.

Its biggest drawback as a mainstream product is that branching and 
merging require you to know a lot more than with other products and
require certain voluntary behaviors that aren't immediately obvious,
like tagging on both branches when doing merges. A few enhancements, 
like tracking moves, renames, and merges will permit reasonable default 
behavior in most situations for those developers who do not have a 
passionate interest in revision control.

Ralph A. Mack


___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: BRANCH LABEL FOR DIRECTORIES

2001-06-19 Thread Greg A. Woods

[ On Tuesday, June 19, 2001 at 08:50:34 (-0400), Ralph Mack wrote: ]
 Subject: Re: BRANCH LABEL FOR DIRECTORIES

  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
 
  However I can't let that sit.  What a downright stupid and misleading
  example.  
 
 This doesn't seem like a manufactured scenario to me - more like something
 that comes up every so often, although I'll admit it has fewer files than 
 the normal case. It looks like what I would do if you had to move the 
 contents of a directory from one place in the directory tree to another? 

There are two differences between Paul's example and the one I gave.
One of those differences is irrelevant to this issue, and the other is
critical.  The irrelevant difference is the use of two files moving from
one sub-directory to another (and the implication that maybe the
directory is also being renamed, though that's not necessarily what's
happening).  The critical difference though is the meaningless and
useless commit and perhaps misleading comment in Paul's example.
 
 How would you do it, Greg? 

I gave a more meaningful and future useful commit comment in my
example.

Paul's example is probably less useful and more misleading than if it
were simply left empty.  At least an empty comment can be more easily
flagged for correction!  ;-)

A future useful commit comment is something that's critical for every
commit in every revision control system, not just one that removes or
adds one or more files, of course.  It's very important for the
committer to always ask themselves the question Does my explanation
clearly and completely describe this change to some future maintainer
who is trying to understand it and its intent?

Paul's message might be sufficient in the form of an e-mail message that
includes all the file names and all the actions (such as one that might
be produced by the log_accum loginfo script).  However to anyone in
the future examining any of the revision histories of any of those
individual files, it will not only be incomplete, but it might even be
misleading.

The only thing special about commit messages for renamed/moved file(s)
in CVS is that they have to be somewhat redundantly worded if they're to
be used identically for both the removed and the added file(s).  However
I don't think they're very hard to devise for anyone willing to take a
moment to think about what they're writing.

CVS is not a replacement for good inter-developer communications, though
sometimes it is the vehicle.

 It isn't enough to say that you simply wouldn't let this happen to you.
 Migrations, even mass migrations, are a fact of life; demands of logistics
 often place their prevention beyond our control; since they cannot be 
 prevented, they need to be supported without damaging continuity.

Once burned, twice shy?  Certainly learning from one's mistakes is
painful.  Luckily in this case the commit messages can be changed after
the fact, at least so long as it is caught before the committer
disappears or forgets what he or she did.

 I don't see CVS as a niche product at all. CVS is as mainstream as Linux
 or Java.

It really doesn't matter how widely used CVS is -- it's popularity is
simply an indication of how commonly people do the things it can do (and
perhaps how commonly people try to use it to do things it cannot do well).

CVS is a niche product because it offers only those specific features
necessary for tracking the change history of source code (including the
source text that might be used to produce documentation), and because it
helps solve a couple of common problems often encountered by users of
more traditional source control systems such as RCS or SCCS.  CVS is a
niche product because it explicitly, by design, does not attempt to
provide a generic change control system that can be used in _all_
scenarios where it is useful to track changes to files stored on a
computer system.  CVS is a niche product because it does not need a
large market share in order to survive (it could survive quite well if
only one person used it).

 Most of what most people need is easy to learn and use, with 
 the exception of branches and merges. Set up is kind of fragmentary, as
 for many Linux services, but it seems to have all the right hooks in all 
 the right places for integration into corporate build mechanisms. Its
 support for Windows clients is adequate. As companies become more 
 accustomed to shareware, I could see it become the preferred version 
 control system for corporate Unix/Linux. If the Windows version could 
 register out of the box as a Win2000 service, I could see it becoming 
 popular for Windows shops, too.

Lots of people would no doubt disagree with at least your claim that CVS
has all the right hooks in all the right places.  Indeed there's
another thread going on right now

Re: BRANCH LABEL FOR DIRECTORIES

2001-06-19 Thread Derek R. Price

Greg A. Woods wrote:

 Ah, but in this case I can.  Everything I've described about tracking
 the renaming/moving of files using cvs rm and cvs add with magically
 meaningful comment strings can be easily automated by a front-end.  No
 change is necessary in CVS itself to achieve this functionality,
 therefore it is provably not a necessary feature of the basic CVS
 functionality.

I agree, although I might argue that if you were the person who were going to add
this functionality, the most efficient place to add it would be on the CVS server
since it shouldn't require any client support and adding the functionality to the
server should make the feature immediately available to most clients on most
platforms.  Besides, storing metadata in log messages is rather messy.

Of course a wrapper implementation could make the feature available on a server
that didn't otherwise support it, but I'd consider that mostly moot since most of
the other features and bug fixes that make it into new CVS releases can usually
justify upgrading.

Derek

--
Derek Price  CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net )
--
As honest as the day is long.

- S. Z. Sakall as Headwaiter Carl, _Casablanca_




___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: BRANCH LABEL FOR DIRECTORIES

2001-06-18 Thread Greg A. Woods

[ On Monday, June 18, 2001 at 00:51:22 (-0700), Paul Sander wrote: ]
 Subject: Re: BRANCH LABEL FOR DIRECTORIES

 No, it doesn't delete it, but it does hide the old stuff (which is just
 as bad).  Once the remove-add sequence is done, there is no reliable
 method to track down the original location, and under some circumstances
 there may even be no way for the end user to recover it.

NO, it does not hide it either.  Any semi-sentient being can find it
in no time at all.

 I beg to differ.  Even in your preferred method, you rely on the user
 to carefully leave a bread crumb trail, by noting the rename in the commit
 comment.

The audit trail is not necessarily dependent on the user -- there are an
almost infinite number of ways to mechanise and automate its creation
(and its tracking too)!

  The version control system should track the rename separately,
 in the version history but separate from the user's comments.

Why?  There's no logical difference.

 You're kidding, right?  Don't support merging across renames?  This
 capability is one of the most basic requirements of any version control
 system worthy of the name.

I think you're living in a dream world of marketing driven featuritis.

I've been using CVS intensively for how many years now?  Eight?  I've
*NEVER* had any major problems with renames, and I don't just avoid them.

 What if you rename the top directory of a deep tree?  That's a LOT of
 manual merging to do.

Why would anyone do anything so idiotic?

  And sometimes the rename is necessary.

No, such things are *NEVER* necessary!  It's a figment of your
imagination.  It might be highly desirable, but never ever necessary.

  And
 sometimes the users expect the rename operation to be both reversible
 and repeatable.  CVS does not provide this capability in any sense.

Ha! Of course some users, such as perhaps yourself, have totally
unrealistic expectations.  That's the nature of the game.  CVS isn't a
market driven product -- it's a freeware niche product.  You're
comparing apples and oranges and then wondering why there's no
consistent taste between the two.

 Okay, let's pick nits and say only that the format of the data contained in a
 file changes.  Let's say that it changes from RTF to HTML.  Strictly speaking,
 the file's type does not change, but using CVS in the normal way produces
 gibberish in certain cases that are easy for the average user to fall into.

Users who do idiotic things like that will get stupid results.  G.I.G.O.

CVS is not a system for button pushing automatons -- you have to think
to use it properly.

 This just would not happen if version histories tracked the entire lifetime
 of a file, not just that portion of its life when it occupied one spot in
 the filesystem.

Fine.  Go use such a system and forget you ever heard about CVS.

 Or, CVS could be changed to really do it right...

In your dreams Paul.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  [EMAIL PROTECTED] [EMAIL PROTECTED]
Planix, Inc. [EMAIL PROTECTED];   Secrets of the Weird [EMAIL PROTECTED]

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: BRANCH LABEL FOR DIRECTORIES

2001-06-18 Thread 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  [EMAIL PROTECTED] [EMAIL PROTECTED]
Planix, Inc. [EMAIL PROTECTED];   Secrets of the Weird [EMAIL PROTECTED]

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: BRANCH LABEL FOR DIRECTORIES

2001-06-18 Thread Greg A. Woods

[ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ]
 Subject: Re: BRANCH LABEL FOR DIRECTORIES

 So why not have CVS do this work OOTB?

You could.  It's been proposed several times before.  Nobody's stepped
up to write the code.  Even though I've also proposed it in the past, my
proposal was in response to someone else's problem and of late I've not
even had time to implement the solutions to my own problems, let alone
anyone else's!  ;-)

It should be quite trivial to add such rename functionality to any of
the more advanced font-ends to CVS (be they either stand alone clients,
or wrappers that just call the existing command-line client).  Even the
handling of the manual parts of merging renamed/moved files could be
done in the client and/or front-end.  There's not even any need to do
anything fancy -- just search back for magic rename comments in files
that had no changes merged and if they are the result of a rename then
go look (recursively) for the ancestor revision in the old file(s) and
manually do the merge on the client side.  Nothing at all needs to be
changed in the repository structure to support such functionality.

If people really want it then _they_ should build it!  CVS is user
supported software!

 How 'bout:  Your company decides to change its name or goes through a merger and
 you're programming in Java?

I'd say that people using CVS for Java (at least with traditional java
development environments) are already on the verge of being in the land
of the truly unsupported anyway.

 In any case, /why/ would it matter why anyone would do this?  The fact is that
 it's a request commonly made.  Your answer seems to be to deem that request as
 being wrong.

People make stupid and idiotic requests of all kinds of things all the
time.  Only marketing departments ever seem to see any need to satisfy
them.  There's nothing wrong with telling someone that their request
is wrong/inappropriate/out-of-place if that's the case.

I thought most of us in the software world were supposed to be more in
tune with doing careful requirements analysis and such.

 In the end, every product is market-driven -- if there's no need for CVS, it
 wouldn't exist.

Sorry, I should have qualified that as mass-market (though I did
qualify CVS as niche market).

 I think Greg has been saying that CVS is a niche product and that it shouldn't
 braoden it's horizons.  So, if:
 1. You have binary files,
 2. You _ever_ need to rename files for the lifetime of your project,
 3. You want to version directories,
 4. You want to reuse a filename that's been rm'd in the past but with a
 different type,
 5. Possibly others I can't think of right now,
 
 then don't use CVS.

Well, not exactly 100% on all those points, but within reason.

In this forum 99.999% of the FAQs that have no existing answer in
context are from people who should not be using CVS in the first place
(or who can't find anything better and are then uwilling to figure out
how to use CVS properly).

In fact there's obviously a very strong demand for something to fill the
niche that CVS fits well into  The only problem is that at least
half the people in the world who are not in that niche seem to think
that they should be able to use CVS for whatever hair-brained idea
they've got too.

If someone wants a tool with broader horizons than CVS then they should
build it (and call it something else, of course ;-).  If it eventually
replaces CVS entirely then that's OK.  If it doesn't then those in the
niche where CVS fits will still have an appropriate tool to use to meet
their needs.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  [EMAIL PROTECTED] [EMAIL PROTECTED]
Planix, Inc. [EMAIL PROTECTED];   Secrets of the Weird [EMAIL PROTECTED]

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



RE: BRANCH LABEL FOR DIRECTORIES

2001-06-18 Thread Chris Cameron

So now you're saying that it could be included OOTB AND that you've proposed
it in the past.  But you've been arguing that this is a BAD IDEA (TM) and
seem to continue that position later in the same e-mail!

I'm just sitting on the sideline and observing this one, but you seem to be
trying to have your cake and eat it!

***
Chris Cameron   Open Telecommunications Ltd
Product Manager   IN Product Management
[EMAIL PROTECTED]   P.O.Box 10-388
  +64 4 495 8403 (DDI)  The Terrace
fax:  +64 4 495 8419 Wellington
cell: +64 21 650 680New Zealand
Life, don't talk to me about life (Marvin - HHGTTG)


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
 Greg A. Woods
 Sent: Tuesday, 19 June 2001 9:04 a.m.
 To: CVS-II Discussion Mailing List
 Subject: Re: BRANCH LABEL FOR DIRECTORIES


 [ On Monday, June 18, 2001 at 15:18:16 (-0400), Noel L Yap wrote: ]
  Subject: Re: BRANCH LABEL FOR DIRECTORIES
 
  So why not have CVS do this work OOTB?

 You could.  It's been proposed several times before.  Nobody's stepped
 up to write the code.  Even though I've also proposed it in the past, my
 proposal was in response to someone else's problem and of late I've not
 even had time to implement the solutions to my own problems, let alone
 anyone else's!  ;-)

 It should be quite trivial to add such rename functionality to any of
 the more advanced font-ends to CVS (be they either stand alone clients,
 or wrappers that just call the existing command-line client).  Even the
 handling of the manual parts of merging renamed/moved files could be
 done in the client and/or front-end.  There's not even any need to do
 anything fancy -- just search back for magic rename comments in files
 that had no changes merged and if they are the result of a rename then
 go look (recursively) for the ancestor revision in the old file(s) and
 manually do the merge on the client side.  Nothing at all needs to be
 changed in the repository structure to support such functionality.

 If people really want it then _they_ should build it!  CVS is user
 supported software!

  How 'bout:  Your company decides to change its name or goes
 through a merger and
  you're programming in Java?

 I'd say that people using CVS for Java (at least with traditional java
 development environments) are already on the verge of being in the land
 of the truly unsupported anyway.

  In any case, /why/ would it matter why anyone would do this?
 The fact is that
  it's a request commonly made.  Your answer seems to be to deem
 that request as
  being wrong.

 People make stupid and idiotic requests of all kinds of things all the
 time.  Only marketing departments ever seem to see any need to satisfy
 them.  There's nothing wrong with telling someone that their request
 is wrong/inappropriate/out-of-place if that's the case.

 I thought most of us in the software world were supposed to be more in
 tune with doing careful requirements analysis and such.

  In the end, every product is market-driven -- if there's no
 need for CVS, it
  wouldn't exist.

 Sorry, I should have qualified that as mass-market (though I did
 qualify CVS as niche market).

  I think Greg has been saying that CVS is a niche product and
 that it shouldn't
  braoden it's horizons.  So, if:
  1. You have binary files,
  2. You _ever_ need to rename files for the lifetime of your project,
  3. You want to version directories,
  4. You want to reuse a filename that's been rm'd in the past but with a
  different type,
  5. Possibly others I can't think of right now,
 
  then don't use CVS.

 Well, not exactly 100% on all those points, but within reason.

 In this forum 99.999% of the FAQs that have no existing answer in
 context are from people who should not be using CVS in the first place
 (or who can't find anything better and are then uwilling to figure out
 how to use CVS properly).

 In fact there's obviously a very strong demand for something to fill the
 niche that CVS fits well into  The only problem is that at least
 half the people in the world who are not in that niche seem to think
 that they should be able to use CVS for whatever hair-brained idea
 they've got too.

 If someone wants a tool with broader horizons than CVS then they should
 build it (and call it something else, of course ;-).  If it eventually
 replaces CVS entirely then that's OK.  If it doesn't then those in the
 niche where CVS fits will still have an appropriate tool to use to meet
 their needs.

 --
   Greg A. Woods

 +1 416 218-0098  VE3TCP  [EMAIL PROTECTED] [EMAIL PROTECTED]
 Planix, Inc. [EMAIL PROTECTED];   Secrets of the Weird [EMAIL PROTECTED

RE: BRANCH LABEL FOR DIRECTORIES

2001-06-18 Thread Greg A. Woods

[ On Tuesday, June 19, 2001 at 11:42:20 (+1200), Chris Cameron wrote: ]
 Subject: RE: BRANCH LABEL FOR DIRECTORIES

 So now you're saying that it could be included OOTB AND that you've proposed
 it in the past.  But you've been arguing that this is a BAD IDEA (TM) and
 seem to continue that position later in the same e-mail!

No, I did not argue that it was a bad idea.  I said that it was not a
necessary feature of a basic source code control system like CVS.

What I and others have proposed are methodologies to work within the
existing feature set of CVS.

I also said such a feature could be included out-of-the-box if someone
would step up and write the code (test it, document it, etc.).  What I
did not say was how it might come out of the box -- it could just as
easily take the form of a little set of shell scripts to be used as
command-line wrappers.

 I'm just sitting on the sideline and observing this one, but you seem to be
 trying to have your cake and eat it!

Ah, but in this case I can.  Everything I've described about tracking
the renaming/moving of files using cvs rm and cvs add with magically
meaningful comment strings can be easily automated by a front-end.  No
change is necessary in CVS itself to achieve this functionality,
therefore it is provably not a necessary feature of the basic CVS
functionality.

-- 
Greg A. Woods

+1 416 218-0098  VE3TCP  [EMAIL PROTECTED] [EMAIL PROTECTED]
Planix, Inc. [EMAIL PROTECTED];   Secrets of the Weird [EMAIL PROTECTED]

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs



Re: BRANCH LABEL FOR DIRECTORIES

2001-06-15 Thread Larry Jones

Alex Flores writes:
 
 In CVS, does a directory have versions as well or do only the files have
 versions.

Only the files.

-Larry Jones

My life needs a rewind/erase button. -- Calvin

___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs