Why not abandon CVS?

[Michael Rasmussen-4]

Hi all,

While transferring from one hosting to another why not abandon CVS at
the same time? What I am thinking at is Git, Mercurial or Bazaar as a
replacement for CVS. Even Subversion would be a step forward:-\

--
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael <at> rasmussen <dot> cc
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xD3C9A00E
mir <at> datanom <dot> net
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE501F51C
mir <at> miras <dot> org
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE3E80917
--------------------------------------------------------------
Forrest Gump: "I'm sorry for ruining your party, Lieutenant
Dan. She tasted of cigarettes"

[Colin Leroy]

On 12 October 2009 at 19h10, Michael Rasmussen wrote:

Hi,

> While transferring from one hosting to another why not abandon CVS at
> the same time? What I am thinking at is Git, Mercurial or Bazaar as a
> replacement for CVS. Even Subversion would be a step forward:-\

Because I lack time to do it. We may move to svn, after we'll have
completed the cvs and MLs migrations; I don't want to do both at the
same time.

--
Colin

[H.Merijn Brand]

On Mon, 12 Oct 2009 19:23:13 +0200, Michael Rasmussen <mir@...>
wrote:

> Hi all,
>
> While transferring from one hosting to another why not abandon CVS at
> the same time? What I am thinking at is Git, Mercurial or Bazaar as a
> replacement for CVS. Even Subversion would be a step forward:-\

+1 for git

our company moved from SCCS to git and thought every VCS has drawbacks,
we all learned to love it. Certainly on the native platforms like
Linux, the GUI tools like git-gui and gitk were very very helpful in
proving that git was a major step forward. (Well, coming from SCCS,
almost anything is).

For our java projects we are still bound to svn, sadly, because the svn
integration in Eclipse and NetBeans is much better than the git
versions of VCS integration. That said, we already had 4 corrupt svn
repositories, and never a single problem with git.

Another advantage of git over svn (and bazaar) is that it has almost no
dependencies, so it is relatively easy to build on non-standard OS's
like HP-UX and AIX. I gave up on svn on 64bit HP-UX after 4 days of
cursing and failure, whereas I had git up and running in 4 hours, which
included the Tk gui's

--
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

---------------------------------------------------------------------
To unsubscribe, e-mail: claws-mail-devel-unsubscribe@...
For additional commands, e-mail: claws-mail-devel-help@...

[Salvatore De Paolis-3]

On Mon, 12 Oct 2009 23:23:37 +0200
"H.Merijn Brand" <h.m.brand@...> wrote:

> +1 for git

I'd like git too to be sincere. I've used it in past, still using time to time
and i think it helps the development better than others.
The only drawback in that is the learning curve from a cvs admin/user pov.
But also i can say i put online a git repo+web interface in few time reading
some tutorial, so isn't something really hard to do.
But of course that's far from knowing every faces of git.

svn seems to bet the good compromise since it's similar to cvs.

Regards
Salvatore

[wwp]

Hello,


On Tue, 13 Oct 2009 08:49:08 +0200 Salvatore De Paolis <iwkse@...> wrote:

> On Mon, 12 Oct 2009 23:23:37 +0200
> "H.Merijn Brand" <h.m.brand@...> wrote:
>
> > +1 for git
>
> I'd like git too to be sincere. I've used it in past, still using time to time
> and i think it helps the development better than others.
> The only drawback in that is the learning curve from a cvs admin/user pov.
> But also i can say i put online a git repo+web interface in few time reading
> some tutorial, so isn't something really hard to do.
> But of course that's far from knowing every faces of git.
>
> svn seems to bet the good compromise since it's similar to cvs.

*If* we'd have to vote, my own one would go to svn. Easy to set up,
robust and efficient enough for what we need, no need to reformat a
cvs-user brain to use it.


Regards,

--
wwp

[Holger Berndt]

On Tue, 13 Oct 2009 09:03:17 +0200 wwp wrote:

> no need to reformat a cvs-user brain to use it.

I consider it an urban legend that DVCSes like git need
cvs-user-brain-reformatting. I guess that depends on what you really
want to do with a VCS. If you just do "cvs update", "cvs diff" and "cvs
commit", those have more-or-less direct equivalents in git. That DVCSes
allow other workflows in addition to that is not a disadvantage, not
even to cvs users.

However, as nobody here is really an expert on git and Paul and Colin
(the ones who do that actual work) are fine with cvs/svn, the choice
should be one of those.

I agree to Salvatore and wwp in so far as that amongst those two, I'd
also prefer svn. Not only because of the technical merits, but also
because of many positive reports I heard from people that use git on
top of svn, which seems to be working well (I've speaken to quite a
few developers who actually thought git was a tool on top of svn,
instead of a separate VCS). So with an svn repo, git-lovers could even
use their toy.

---------------------------------------------------------------------
To unsubscribe, e-mail: claws-mail-devel-unsubscribe@...
For additional commands, e-mail: claws-mail-devel-help@...

[H.Merijn Brand]

On Tue, 13 Oct 2009 09:39:57 +0200, Holger Berndt <berndth@...>
wrote:

> On Tue, 13 Oct 2009 09:03:17 +0200 wwp wrote:
>
> > no need to reformat a cvs-user brain to use it.
>
> I consider it an urban legend that DVCSes like git need
> cvs-user-brain-reformatting. I guess that depends on what you really
> want to do with a VCS. If you just do "cvs update", "cvs diff" and "cvs
> commit", those have more-or-less direct equivalents in git. That DVCSes
> allow other workflows in addition to that is not a disadvantage, not
> even to cvs users.
>
> However, as nobody here is really an expert on git and Paul and Colin
> (the ones who do that actual work)

I wholeheartedly agree that the people that do the actual commits are
the ones that should choose. Not the lurkers or the occasional patchers
(like me).

> are fine with cvs/svn, the choice should be one of those.

There I still have doubt.

> I agree to Salvatore and wwp in so far as that amongst those two, I'd
> also prefer svn. Not only because of the technical merits, but also
> because of many positive reports I heard from people that use git on
> top of svn, which seems to be working well (I've speaken to quite a
> few developers who actually thought git was a tool on top of svn,
> instead of a separate VCS). So with an svn repo, git-lovers could even
> use their toy.

I work with all all these:
* git local
* git remote (push/pull/merge)
* git on svn
* svn remote

Setting up git on svn is dead easy, but time needed for the original
synup is extremely high (for the computer, not for the user: it is
very very slow). I use this for helping with perl/Tk and my own
submissins to DBI (perl database interface). The owner of the svn repo
is still hape, so from my pov I see git, commit in git and push to svn

Even with git local, I make backups using git push to the backup box.
The backup repo is not used at all, but in case of trouble, I just make
a fresh clone.

git remote is what I use for perl5 development. This is probably what
you'd use for S-C if you'd choose for git.

snv robust? Maybe, but I have had *several* busted repo's locally that
I had to rm -rf and re-clone to move forward. That at least is an
advantage of DVCS's over local only. You always have a backup. Let's
just hope that backup is backed up and stable.

As a last remark from the user field, a small pro/con:
+ SVN: many user interfaces available (your favourite UI will be
  supported (Qt, Tk, X11, ...)
- SVN: many user interfaces available (what/which to choose)
- SVN: reporting tools on the server side
+ SVN: (very) good integration in IDE's
+ GIT: good GUI's
- GIT: none of the GUI's offers *all* functionality. git-gui is for
  what is currently happening (see changes, commit, push), and gitk is
  for viewing the past (search commits, view merges, check hist)
+ GIT: easily scriptable. Good interface to low-level functions
+ GIT: extremely fast (and small on disk usage)
+ GIT: integration with mailed patches ('git am' is a real time saver)
  I have no idea if SVN does have something similar

Both have active development (unlike SCCS)

The *complete* perl VCS history, as converted from perforce
$ du -sk .git
83548   .git

First recorded commit:

commit 8d063cd8450e59ea1c611a2f4f5a21059a2804f1
Author: Larry Wall <lwall@...>
Date:   Fri Dec 18 00:00:00 1987 +0000


--
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

---------------------------------------------------------------------
To unsubscribe, e-mail: claws-mail-devel-unsubscribe@...
For additional commands, e-mail: claws-mail-devel-help@...