Re: hello ..

[Pavel Roskin]

Hello!

> One of the difficulties of merging the projects is that we've got very
> different choices in terms of implementation languages, we have some
> overlapping commands (my fault; when I came up with `cvsu', I didn't
> know of the other, totally unrelated implementation thereof, so I
> should rename it some day), a little bit of overlapping functionality.

I didn't know that you also have cvsu!

> IMHO, the hardest problem to solve is that of implementation language.
> You'll hardly find me willing to write or maintain stuff in Perl, and
> Pavel would probably dislike having to do it all in plain shell script
> either.

I'm not a fan of Perl either.  However, Perl is much faster.  I'm using 
cvsu very heavily at work on a huge repository, and I'm not going to 
switch to a tool that does the same thing, but slower.

> Perhaps the solution is for both of us to agree to rewrite everything in
> Python?  I've been meaning to give myself a reason to learn Python for
> real, and I've got FranГois Pinard's implementation of clcommit in
> Python as a starting point... :-)

Sounds like a good idea.  All my development machines run Red Hat 8.0, so
I have Python 2.2.1 on them.  Python 1.x and 2.x are quite different (e.g.
with regard to environment variables).  I suggest that we require Python
2.x from the beginning.

I'm quite busy with other things, but I'm ready to spend some time on the 
tools I'm using every day.

> But then, subversion is on the corner, and I'm not convinced rewriting
> these CVS-specific scripts is worth the effort.  Perhaps we should
> wait for the world to be subverted and then convert whatever is found
> to be missing in it to either a set of helper scripts like this, or
> fold the features into subversion proper...

I tried subversion one month ago.  The biggest problem is that it's very
slow.  "svn update" takes several minutes on a project that includes Linux
kernel, gcc, binutils, pcmcia-cs and some command-line utilities.  It's a
local update is on a Red Hat 8.0 system with Athlon 1.2GHz and 512Mb of
RAM. Everything was up to date, I did it just in case, like I do it with
CVS. With such performance, I would be discouraged to update the project
too often even in multi-user environment.

Another problem is that subversion is tied to apache and is harder to
install compared to CVS, especially for local development, when installing
CVS doesn't even need root access.

One more inconvenience - subversion keeps base versions in the .svn 
directories.  Not only does it double the required disk space, but it also 
doubles the time searching for substrings, and it gives you two files 
unless you exclude .svn directories from the search.

Given all the above, I don't think it's realistic to expect any
significant projects to be "subverted" in the next year or two.

On the other hand, if the United CVS Utilities (ucvsu?) is written in 
object-oriented Python, it should be possible to have a separate backend 
for subversion.

CVS and subversion are both about versioning, not about development, let
alone development of GNU software.  They don't provide tools e.g. for
checking ChangeLog.  This means that CVS Utilities can be useful with
subversion some day, and maybe even with arch.

-- 
Regards,
Pavel Roskin