tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

End-user VCS thoughts



Hello,

As there is some pressure on deprecating CVS, I'm going to give my
end-user perspective feedback.

My beard isn't too long, as my first VCS was Subversion. Later I used:
fossil, mercurial and git. Back in 2013/2014 I disliked CVS because I
believed that it's obscure and dead, so it's lost of time to master it.

I'm just going to give some points that matter to me and only to me.

CVS:
+ best for low bandwidth or fragile connections, actions are "resumable"
+ enforces CI flow (merge and commit)
+ reduces messing with renaming etc (partly in pros and cons)
- no full repo & history locally
- after renaming file (delete and create in new place) no history
preserved

GIT:
+ great for development in general
+ full repo and history locally
+ powerful rebase (rewrite history)
+ cherry-picking between clones
- bad option in a low-bandwidth and fragile connection environment
- very slow operations (diff, status, log...) in larger repositories
- memory eater

With git I was unable to push NetBSD full sources and pkgsrc
(without history, just plain CVS checkout) to GitHub due to timeout or
connection dying. My walk-around was to partition sources and use
submodules.. it's extra burden to maintain that and it introduces
problems with file renames known from CVS.

With git I was too inpatient to work with full NetBSD sources in one
git repo (my hardware was stronger amd64 platform)...

HG:
It mostly shares pros and cons of git, plus there is one extra
deficit: Python non-portable dependency, making some of our ports
not self-contained.

FOSSIL:
It tries to do everything, but in annoyingly little extent.
Fossil also enforces ideas of Version Control of the authors,
not applicable in all projects (most notably no history rewrite).

The backed of sqlite as being pointed in the threads isn't promising
for large projects.

SVN:
Similar to CVS. Better for history browsing, worse for fragile
networks.

To summarize it, I'm in favor of preserving CVS in the back-end storage
and maintain official cvs->git mirror for developers.

When renaming files in CVS, I'm for not "fixing" the back-end, but to
just delete a file and recreate in a new place, DVCS will take care of
tracking the history.

FreeBSD does something similar tracking SVN with
https://github.com/freebsd/freebsd

There is an unofficial mirror of the NetBSD sources at
https://github.com/jsonn/src unfortunately few days behind CVS.
The mirror of FreeBSD is up to date and used for some of their
official projects, developed primary in git.

Moving to git won't give us auto-magically more users or developers,
EdgeBSD and Bitrig, both forked hoping for git development don't have
many new devs who came for DVCS hacking.


Home | Main Index | Thread Index | Old Index