Re: [Monotone-devel] Merging cvssync in small pieces: Pipe abstraction

[Zbynek Winkler]

Chad Walstrom wrote:

> > I've converted to Mercurial and I had 2 main reasons:
> >
> > 1) not being able to compile monotone with gcc -- Mercurial is in Python
> >    
> I believe there are pre-compiled, static binaries floating about, and
> RPM and DEB packages provided on the Monotone website.
Yes, but using only prebuilt binaries prevents me from being able to 
play with it, change behavior I do not like etc. I remember I had an 
idea I wanted to try but failing to compile database.cc scared me away :(

> > 2) the need for custom 'server' and not being able to easily use one
> > machine for multiple projects (one running instance of monotone
> > handles only one database and I didn't want to put unreleated
> > projects to the same database) -- Mercurial can export repositories
> > over http using a Python cgi script (I can have as many different
> > repositiories exported as I want) and any user with the right to
> > execute cgi script can export repo without additional privileges
> >    
> I had played with Mercurial (Hg) a bit and might be using it today if
> I didn't have to work with other people. ;-)  When reviewing the
> various SCM's out there (including Hg), we came to the conclusion that
> Monotone's commands were simpler and less prolific than other tools
> and its work-flow was easy enough to follow.  
AFAIK the work-flow is pretty much the same for both.

> Monotone's FAQ and
> documentation convinced me that the use of GnuPG for signing had its
> flaws, and that Monotone's answer in libcrypto++ was more than
> sufficient.
>  
crypto++ had its share of flaws so it was replaced (?). I don't have an 
opinion on what's better in this case (GPG or something else).

> And perhaps it was in no small part to Nathan's visibility on SCM
> related blogs, pushing his favorite one, that convinced me to take
> another look. ;-)
>  
Yeah ;-) I am still hanging around too.

> Really, I think the deciding factor for my team-mates was the Windows
> support.  Hg was designed (as are many SCM's) with *NIX environments
> in mind.  The creator of the tool admitted that he had no interest in
> trying to address Windows environment issues, such as piping, CRLF
> conversion, etc.  I'm sure the project has since collected a Windows
> development expert or two, but at the time, the comment was
> discouraging enough to tip the argument in Monotone's favor.
>  
I've originally started with monotone as well. But recently all the 
above mentioned features were added to hg (I might have helped a bit 
;-)). That was when I decided to give it spin in our group.

> I don't find the use of the smart server to be a detriment, even if
> there is a small extra step to configure the ACL's to the database
> (which I actually find encouraging from a security-conscious point of
> view).  The work-flow may involve an extra step (or two, if you want
> to tunnel over SSH), but if you recall correctly, Hg supports such a
> command as well.  It has a built-in simple HTTP server (ala Python
> libraries) that doesn't just run itself. ;-)
>  
Well, the thing is that all of this is very easy with hg. We already had 
a svn repo setup with ssh access for a group of developers so it was a 
matter of minutes to create a hg repo, move it to the shared space 
accessible by ssh and push the code into it. Adding email notification 
took some effort but it is now fixed upstream so I am happy I could 
help. Other than that - no "extra steps" were required.

> In any case, I'm committed to using Monotone now. I'm looking forward
> to the usher code and cvssync code making its way into the main tree.
> ;-)  Great work guys!
>  
That is true! Keep up!

Zbynek

--
http://zw.matfyz.cz/     http://robotika.cz/
Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic