Subject: Renaming files?

From: [email-masked] (Paul D. Smith)
Date: 16 Mar 1999 20:38:57 -0500

I'm working on some updates to cvs.html and I notice we have categories
for adding and deleting files, but no instructions for renaming files.
Since I'm going to try to do some renaming in the near future, can we
decide what method we want to use for this?  Then I'll write it down.

What have we used in the past, and is that how we want to recommend we
do it in the future?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Tue, 16 Mar 1999 22:20:17 -0500

> What have we used in the past, and is that how we want to recommend we

I've done some renaming in the past.  The method is to delete and add.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Jason L Tibbitts III <[email-masked]>
Date: 16 Mar 1999 21:52:14 -0600

>>>>> "DE" == Dan Espen <[email-masked]> writes:

DE> I've done some renaming in the past.  The method is to delete and add.

The only useful thing to know is that the delete should note the name of
the new file and the add should note the name of the new file:

cvs delete -m "Renamed to newfile" oldfile
cvs add -m "Renamed from oldfile" newfile

(I think...)

 - J<

---

From: [email-masked] (Paul D. Smith)
Date: 16 Mar 1999 23:30:48 -0500

%% Dan Espen <[email-masked]> writes:

  de> I've done some renaming in the past.  The method is to delete and add.

OK.  Seems a shame to break the history; the renamed file looks like a
brand new file in this scheme, instead of the old file renamed.

There are fancier methods, all with various advantages and drawbacks,
discussed in the CVS manual (which is why I asked) but if this is the
way we're going that's OK w/ me :).

Too bad CVS hasn't implemented directory versioning--ClearCase has the
most kick-butt implementation of this I've ever seen (and I've seen a
lot of these :).  It's completely excellent.  You can rearrange the
entire tree to look completely different, including renaming files,
moving files, etc., and switch back and forth from old to new with a
flick of a file.  _And_ all history, labels, merge arrows, etc. are
perfectly preserved.  Nice.  But, big $$$ too :).

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 17 Mar 1999 07:13:05 +0100

> perfectly preserved.  Nice.  But, big $$$ too :).

At first I didn't want to comment on this thread, but now that you start
recommending ClearCase as a good tool for directory versioning I have
to disagree. In theory it can do all you describe, but when it comes
down to versioning branch directories it's heavily buggy. You can get
a host of unwanted effects (like seeing a file of a different branch
or even three different versions in just two branches). And don't
let us speak about being able to delete files without checking out
the directory. ClearCase has given me a lot more headaches than CVS
has, and I use CVS much more often.

Bye

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: [email-masked] (Paul D. Smith)
Date: 17 Mar 1999 10:38:01 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> At first I didn't want to comment on this thread, but now that you
  dv> start recommending ClearCase as a good tool for directory
  dv> versioning I have to disagree. In theory it can do all you
  dv> describe, but when it comes down to versioning branch directories
  dv> it's heavily buggy.

No, it isn't.  Versioning and branching directories works exactly as it
should, once you grok the logic (which is almost identical to how UNIX
filesystems work, handily enough), and is actually much simpler than
versioning and branching files (mainly because merging directories is
always simple).

This is 'way offtopic and we can continue it offline, but I've been
using ClearCase intensively every day for almost 4 years now.  I've
implemented a sophisticated (if I do say so myself :) changeset system
on top of it, so I know a lot about the nooks and crannies.  I've also
used a lot of other systems, from raw SCCS and RCS, to PVCS, to CVS, to
Perforce, to various free and homegrown systems.

Our changeset process makes _extensive_ use of branches, including
directory branches; you can't add, remove, or move a file without
branching a directory or two.  We have almost 10,000 branch types in our
largest project right now, and we add more every day.  Works perfectly.

ClearCase has some serious problem areas, without question, but this
(directory branching/versioning) is not one of them.  There is only one
possible hazard with branching directories, and it's both unavoidable
(IMO) and easily handled by installing a trigger script.

I've been using it since ClearCase 2.0 was released (1995); I've heard
that CC 1.0 had some very strange "features"; maybe that's what you're
thinking of?  It's come a _long_ way since then.

  dv> You can get a host of unwanted effects (like seeing a file of a
  dv> different branch or even three different versions in just two
  dv> branches).

Only one version of a file or directory can ever be selected by the
view (config spec) at one time.

If you construct your config spec specifically to see different files on
different branches at the same time, then you certainly can do so.  This
is a feature: for example, unlike CVS where when you create a branch all
the master files in the repository have a branch created, in ClearCase
typically branches are only created for files which actually change on
the branch: the config spec provides you with a "cascading selection"
mechanism to deal with this.  This is 'way cool, for lots of reasons.

The config spec is very flexible.  Playing with its more powerful
features, like time-based rules, etc., can definitely create some odd
effects, I admit.

  dv> And don't let us speak about being able to delete files without
  dv> checking out the directory.

I'm not sure what issue you are trying to bring out here: you cannot
"rmname" ClearCase elements without checking out the directory--are you
saying that's good or bad?

Removing (or moving or renaming) an element in ClearCase, just like the
UNIX filesystem, actually modifies the directory the element is in (and
the target directory if you're moving it), not the element itself.
Certainly you can't modify any element, even a directory element,
without checking it out first.  This is A Good Thing (many would say).

  dv> ClearCase has given me a lot more headaches than CVS has, and I
  dv> use CVS much more often.

Correlation? :)

If CVS could do all the things ClearCase can, it would by necessity be
similarly complex.

Obviously if you don't need the complexity, then it's better to go with
something simpler.  We certainly don't need the complexity for
FVWM--although (full circle...) it would be nice to have real directory
versioning...  To paraphrase Yogi Berra, you never need the complexity
until you need it :).