On 7/20/06, Daniel Veillard <veillard@redhat.com> wrote:

On Thu, Jul 20, 2006 at 01:59:43PM -0700, Diwaker Gupta wrote:

...

Given that most Xen related stuff (including virt-man) lives in Mercurial repositories, it seems a little weird (and a little cumbersome) that libvirt continues to use CVS. This issue briefly came up on the list once earlier, but didn't go anywhere. Is there any strong reason why libvirt can't move to Mercurial?

I know how to manage secure access to a CVS server, add users, write access, provide anonymous access and snapshot to tarballs. I have no idea how to do this with a mercurial server, that's #1 reason. I want the source code tools to be hosted on a server I manage too. Why do you think it is weird ? libvirt is not part of Xen source tree. You should not have to recompile libvirt when you compile Xen (and vice versa) so where is the problem for you ?

I don't particular have a "problem" with CVS. My argument is simply this: for read-only anonymous access (which usually is the majority), Mercurial is infact easier to setup than CVS; for commit access, Mercurial fixes a whole bunch of *known* CVS problems (atomic commits, disconnected operation etc). Further, since libvirt is still fairly new, it would be easier to make the switch now rather than later. Finally, you're right that libvirt doesn't require compiling Xen -- I mentioned that simply to say that since these are "related" software projects, it is convinient for developers to just use one set of tools across the baord rather than a different thing for each project. Of course, its your call. Just my 2c. Diwaker -- Web/Blog/Gallery: http://floatingsun.net/blog

On Fri, Jul 21, 2006 at 03:13:17PM -0400, Daniel Veillard wrote:

On Fri, Jul 21, 2006 at 11:45:28AM -0700, Diwaker Gupta wrote:

...

I don't particular have a "problem" with CVS. My argument is simply this: for read-only anonymous access (which usually is the majority), Mercurial is infact easier to setup than CVS; for commit access, Mercurial fixes a whole bunch of *known* CVS problems (atomic commits, disconnected operation etc). Further, since libvirt is still fairly new, it would be easier to make the switch now rather than later. Finally, you're right that libvirt doesn't require compiling Xen -- I mentioned that simply to say that since these are "related" software projects, it is convinient for developers to just use one set of tools across the baord rather than a different thing for each project.

I just followed the mercurial presentation at OLS, and asked a couple of questions. Seems it should be possible to still operate in a centralized mode with push for people with commit rights, so I may switch if I manage to get my head around it and find the time needed to setup and test. But don't hold your breath, I think there is more pressing issues :-)

If you do ever want to look at it, I maintain a small administrative tool called 'mercuriual-server-tools' which can ease setup and administration mercurial server. From a single master config file it will automatically create UNIX user accounts, groups, create the repo on disk, set permissions and group ownersip on files, create Apache configs, CGI for anonymous access to nominated reposotories over HTTPm and finally generates SSH authorized_keys files with very restrictive settings to only allow access to nominated mercurial repositories - no general shell acccess. Without it I was constantly forgetting to do one or more of the steps when creating new repositories. Of course its available from a mercurial repo: http://hg.berrange.com/tools/mercurial-server-tools--devel Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|