[linux-cifs-client] dbench performance on cifs to Samba

[Steve French]

James Roper wrote:

> Steve,
>
> Just out of interest, what do you see happening as far as the cifs vfs 
> client is concerned while the kernel is transferred into a new SCM 
> system?  Will development stop for a while, will we switch immediately 
> to the new tool or will we still work in bitkeeper for a while and 
> then gradually switch over to the new tool?  Would it be better to aim 
> to have any uncommitted work committed before that happens or after, 
> or doesn't it matter?
>
> James

Development has not stopped, but for the last three weeks nothing has 
been merged with mainline (although akpm has picked up my the cifs 
bitkeeper tree for the -mm kernel as usual)..  At first I expect to send 
diff -Nau patches to mainline in the future (as in the dark ages), which 
is somewhat more awkward for me (due to the difficulties of tracking 
patch duplication and automerging).  I do expect to keep the 
cifs.bkbits.net bitkeeper and linux-cifs subversion tree in sync more 
often.  Since bitkeeper produces sets of patches easily (e.g. e.g. 
running the script csets-to-patches), I will probably use 
cifs.bkbits.net for a while longer - considerably longer if 
linux.bkbits.net is still maintained by bitmover as they indicated that 
they would do (since that solves the problem of not having patch 
duplication and solves most of the automerge problems).

When the kernel SCM tooling ("git" and possibly "monotone" and "quilt") 
mature enough, I will consider moving but there seems to be no hurry.   
For those (probably the majority) of users who don't have commercial bk 
licenses I would have to keep the samba svn uptodate more often in any 
case - so the big extra work I have is just keeping the trees (bk and 
the three svn trees - for mainline SLES9 and RHEL4/SuseWorkstation/FC3) 
in sync.