Re: CVS is dead

On Thu, 2007-12-27 at 17:19 -0600, Les Mikesell wrote:
Martin Marques wrote:

CVS has problems caused by all of the history being kept in a single
file (it doesn't understand directory operations like renames), but the

Oh, and the fact that commits are not atomic so that if two chagesets
collide (well, CVS doesn't have notion of changeset, only of single file
changes) very bad things can happen (one changeset locks a file that the
other changeset has to update) and you get a corrupt copy that has to be
fixed.

Subversion, git and Mercurial (and others) addressed this issue adding
atomicity to the chagesets (see that with these VCS files don't have
version there are changeset versions).

up side is that you can track development 'forwards' from any point.

Uhh???

$ hg up -r SOME_OLD_REV

Start from a tagged point in development. Branch several times for
different changes. Can you find all subsequent work?

This doesn't make sense from a SVN paradigm, and I'm pretty sure it's
just a difference of semantics. You _can_ d/l the entire repo, or if
you want to, follow revision numbers and see what was done. SVN keeps
trunk, tags, and branches isolated; if you follow the revisions of just
trunk, you only see the revisions of trunk.

(same with svn or git-update).

With svn, there's no way to start from an earlier tag and follow
future tags/branches of that same file.

What? Les do you really know what you're talking about?

I'd like to hear that I don't. With CVS, if you have any of the
development you have all of it. With svn, tags are (by convention) dead
end snapshots and there is no way to track forward development. Assume
you worked on something some time ago, ending by creating a certain tag.
Now several other people create branches for additional work. How can
you tell that, starting from the tag you last knew about? You could
start from any of the branches and work backwards but you can't see what
branches were created or when going forwards.

Yes, tags are by convention a dead-end. The concept of a "tag" is also
at the root of the concept of a "tagged release". I would say that by
convention, a release won't have anymore development done on it.

Branches are for the ability of making (possibly radical) changes
without disrupting the main trunk. Some branches merge back into trunk,
some don't.

This must be even worse in distributed VC's where the changes might
not even exist in your copy of the repository. Doesn't it bother you
to know you might be repeating someone else's mistakes because you
can't track all the other changes from a given point?

What mistake if it's not in the repository?

That's the point - you won't know.

A SCM is not a replacement for communication and normal team dynamics.
It is a tool to /help/ with managing and tracking changes to source
code.

The same thing would happen with CVS if you were coding without
commiting to the main server. Nobody will be able to know what you are
doing. Same if your coworkers don't update regularly. How can they know
what you fixed?

If you aren't committing to the central repository, you aren't using CVS.

In distributed VCS you use pull and push for this.

How can you tell whether that was always done or not?

--
Les Mikesell
lesmikesell@xxxxxxxxx

That all said, if you like CVS, you like CVS. If an organization (i.e.
Fedora) wants to use a specific SCM, I'm sure there are reasons for it.
I would hope that in deciding what tool to use, one would weight all the
features and match them with your work habits/procedures/policies.

There's more than one way to skin a cat for a reason.


--Tim
_________________________________________________________________________
/ In Africa some of the native tribes have a custom of beating the ground \
| with clubs and uttering spine chilling cries. Anthropologists call |
\ this a form of primitive self-expression. In America we call it golf. /
-------------------------------------------------------------------------
\
\ \
\ /\
( )
.( o ).

--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

Relevant Pages

  • Re: BK kernel workflow
    ... > was two commits in BK but one commit in CVS. ... > 96% of the time you'd get the same patch from each system. ... A large number of CVS commits are really also single BK commits (let's say ... send the line "unsubscribe linux-kernel" in ...
    (Linux-Kernel)
  • ld-elf/libc problem? (was: php3/php4 problem)
    ... Two months ago, after a thorough tracking of commits to STABLE, I've built ... cvs co -r1.10.2.2 include/dlfcn.h ... MFC: ... Revision Changes Path ...
    (freebsd-hackers)
  • Re: Setting up a CVS server
    ... CVS, that's so 2000. ... no. CVS tags need not mark branch points. ... Tagging only parts of the repository can also be useful for subsystem ...
    (comp.sys.acorn.programmer)
  • How do you keep track of whats been merged in CVS?
    ... I ask this here because FreeBSD is managed by CVS... ... My understanding of the FreeBSD development model is that "current" is ... the CVS trunk, "stable" is a branch started at the latest release tag, ... cause a file on a branch to track HEAD on the trunk automatically? ...
    (freebsd-questions)
  • Re: Git help for kernel archeology, suppress diffs caused by CVS keyword expansion
    ... diffs caused by CVS keyword expansion. ... people checked into CVS and then posted CVS diffs to fulfill their GPL ... CVS keywords from the kernel sources. ... Common argument for $Id$ tags has been, that upon a problem, a user ...
    (Linux-Kernel)