Re: cvs commit: src/libexec/ftp-proxy ftp-proxy.c src/libexec/rexecd rexecd.c src/libexec/rlogind rlogind.c src/libexec/rshd rshd.c src/libexec/telnetd sys_term.c src/sbin/disklabel disklabel.c src/sbin/mount_portal activate.c src/usr.bin/rsh rsh.c .

["Sepherosa Ziehau" <sepherosa@xxxxxxxxx>]

On 5/25/07, Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> Matthew Dillon wrote:
> > :
> > :On 5/18/07, Matthew Dillon <dillon@crater.dragonflybsd.org> wrote:
> > :> dillon      2007/05/18 10:05:13 PDT
> > :
> > :>   1.15      +52 -32    src/sbin/disklabel/disklabel.c
> > :
> > :Funny, I don't remember doing all that disklabel work :-)
> > :
> > :Thanks,
> > :Nuno
> >
> >    Oops. Nope, that was me.  It snuck in there.  I'll fix the comment in
> >    the cvs log.
>
> Could you please also change the commitid field when changing the comment?  Some CVS tools (namely my CVS converter) do use this field and consequently will merge this commit back together, despite having different commit messages.  I think there was another edit a couple of weeks ago as well.
>
> Talking about CVS, I think the time has come that we *slowly* should think about alternatives and how they would fit with our development process.  I don't say we should switch, I'm just saying that we shouldn't close our eyes and ignore alternatives which might work better in our work flow.
>
> My personal favourite is git, which is backed by a very nice and responsive community (same goes for mercurial) and which provides a powerful toolset and therefore flexibility.
>
> Matt, I know that you are conservative regarding DragonFly's infrastructure, and I think this is the right way to do it.  However I think this doesn't mean that we have to stick to CVS forever.  If there is a tool which is more reliable than CVS *and*

How do you measure reliability?  I don't remember any other version
control system that serves open source community as long as CVS.

Best Regards,
sephe

--
Live Free or Die