On Sat, May 3, 2008 at 2:01 PM, Vasiljevic Zoran <[EMAIL PROTECTED]> wrote:
>
> On 02.05.2008, at 21:50, Vlad Seryakov wrote:
>
>> Frankly, i would go from CVS to SVN/Mercurial/Git, whatever.
>> I still think SF CVS sucks, so i would switch anytime if my voice will
>> need to be counted:-)))
>
> It seems as I'm the only one advocating continued use of CVS...
> And I have a simple reason: I do not see any benefit undertaking
> this (abandond-CVS) effort. What is to be gained? Or, perhaps,
> whar is that we are loosing by sticking to CVS?
I am too lazy to write that essay. You should try it out to see what
you're missing out on. Here's a starter:
mkdir ~/in ~/co
hg clone http://freehg.org/u/groks/naviserver/ ~/in/naviserver
hg clone ~/in/naviserver ~/co/ns-work
cd ~/co/ns-work
hg log -l 10
(I haven't updated the hg naviserver repo recently)
Try exporting some of your recent changes to the naviserver cvs repo
as patches, and then importing them to the hg repo.
Enable the mq Mercurial Queues extension:
# ~/.hgrc
[extensions]
mq=
Enable mq for your repo:
hg qinit
Import a few patches:
hg qimport ~/driver-send-recv.diff
hg qimport ~/nsjob-cancel.diff
hg qimport ~/nsjob-handle.diff
hg qimport ~/driver-send-recv-backout.diff
hg qimport ~/nsjob-errorcode.diff
hg qimport ~/nsjob-deadlock.diff
Check the repo:
hg log -l 10
hg outgoing
hg help outgoing
You could imagine that this is what you actually did -- you committed
a handful of patches locally before pushing them to the public repo.
Because you haven't typed 'hg push', you can change your mind.
For example, you could completely remove the send-recv patches:
hg qpop -a
hg qdel driver-send-recv.diff
hg qdel driver-send-recv-backout.diff
hg qpush -a
hg qseries
hg log -l 5
hg serve -v
I think the big advantage is that you it encourages you to write
better patches and it encourages better collaboration. There are
technical benefits as there were with subversion over cvs, such as
renames and atomic commits, but they're not day-to-day important.
It's that it encourages you to write high quality patches because
you're not worried about merging in your changes before some one else
touches the same files, you can break large changes down into a series
of well commented changesets -- a patchest, and you can edit your
patches into something coherent before you push to every one else.
Give it a try.
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
