Re: GWindows and David Botton

[Brian May <bam@snoopy.apana.org.au>]

>>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:

It sounds like Samuel Tardieu <sam@rfc1149.net> as more experience
then me at using TLA in large posts, so read his posts too. Some of my
thinking may still be CVS orientated, as most projects I use it there
is only one contributor (currently).

    Stephen> The question is whether the SourceForge servers are
    Stephen> running the TLA server software (I assume there is a
    Stephen> server executable?). As far as I know, they are not. Nor
    Stephen> does the typical user (that's us) have the permission to
    Stephen> run new code on the servers.

There is no such thing as a "TLA server" as such.

Instead it uses whatever server you currently have, e.g. apache, sftp,
etc.

All TLA needs is commands to retrieve given files, the client does the
rest of the work. For better support directory listed support is also
required, but there is an easy method to work around this for HTTP, by
putting the directory list into a downloadable file.

TLA, unlike CVS, doesn't require write access to the server, this
eliminates many security bugs with CVS in one go (last I heard
anonymous read-only CVS access has considered extremely insecure, as
CVS was never designed for anonymous access).

This means, to use TLA on sourceforge, all you need to do is dedicate
part of the sourceforge website for TLA, and mirror an official
repository onto a dedicated location on the sourceforge website.

Other alternatives may include using sftp to a read/write location on
sourceforge, or using <URL:http://alioth.debian.org/> (which is
Debian's version of sourceforge; I believe it has similar features but
also supports subversion and TLA).

    Stephen> Hmm. It seems somehow "wrong" to host a Windows project
    Stephen> on a Debian server :).

Nonsense. There is a special section for Microsoft products.  AFAIK,
The only requirement is that the project must be open source.

    Stephen> Do you have any insight into the reliability of alioth? I
    Stephen> know Debian in general strives for reliability over
    Stephen> wizzyness. But it is an all-volunteer organization. So
    Stephen> for our purposes, I think SourceForge is a better choice.

I can't really vouch for the reliability. I haven't heard of any major
issues for a long time now. It is easy to make copies of TLA archives
though, so if you a worried about reliability in terms of "I might
loose my work", keeping a backup on another server may be a good idea
(regardless of what server or source code revision system you use).

    Stephen> Ok, that would be useful in some situations. But I'm not
    Stephen> too worried about that sort of thing.

It seems like you should be. If somebody breaks into the sourceforge
server for instance, it is impossible to know what malicious damage
they may have done to what projects. You have to check each and every
line of source code in every repository. Even then, you need warning
that somebody broke in.

It was be nice if this wasn't an issue, unfortunately it is a real
problem.

In my previous posts, I completely forgot to mention a major advantage
- changesets. With CVS, when you check in a set of changes to multiple
files, the change to each file is considered separate. That means,
while in the middle of committing a large set of changes, somebody can
do an update and get a broken version. It also makes it harder to undo
specific changes, you need to work out all related files, and the
related versions first.

With TLA, each change is called a "changeset". A changeset can
incorporate changes (including file renames,deletions,additions) to a
set of files. This makes it easier to identify everything a developer
did in order to make a change. It is also a strict atomic unit, you
either get none of the changeset, or all of it.

Obviously, there is also a related learning curve here. To use this to
its maximum potential, it isn't a good idea to make numerous unrelated
changes, and commit them all at once. Instead you make "one distinct"
change at a time, and commit it. There are techniques to learn in case
you start making major changes, and find that there is an unrelated
bug you have to fix first. Also, knowing what a "distinct" change
means is a matter of personal judgement and experience.

    >> * It requires a new mind set, and old CVS concepts have to be
    >> forgotten and relearnt.

    Stephen> Hey, we want people to learn new concepts (Ada vs C,
    Stephen> etc); that's a plus :).

Agreed ;-).

    >> * It was built by a developer who hates Windows. As such,
    >> Windows support is still not official.

    Stephen> That's obviously a killer for an explicitly Windows-only
    Stephen> project.

Yes. Although may want to talk to the developers of the Windows ports
before deciding based on this point.

    >> * The lead developer likes command line tools, e.g. patch,
    >> reject files, etc. Some people may not like the absence of a
    >> GUI interface.

    Stephen> I need an Emacs interface. As in I won't use it without
    Stephen> one.

IIRC, the lead developer (Tom Lord) uses emacs. I would be surprised
if this hasn't been considered in detail...

The only emacs feature I use, is its built in ability to handy reject
files. (I am a vim fan <grin>).

    Stephen> Have they ever seen Emacs pcvs? That's far and away the
    Stephen> best user interface to a CM tool I've ever seen.

There seem to be a list of emacs interfaces at
<URL:http://wiki.gnuarch.org/moin.cgi/Additional_20Tools>, under the
"Emacs interfaces" section. Some look like they could be very
good. Sorry, I haven't used any.

    >> * Some commands are low level compared with other source code
    >> revision systems. There is no "annotate" command for example
    >> (although you can get it with add on software). There is no
    >> single command to compare two arbitrary versions (although
    >> comparing the current checked out version with the same version
    >> in the repository is easy; Also finding a list of change-sets
    >> that aren't in your checked out version is easy).

    Stephen> That's what the Emacs interface is for; you build
    Stephen> user-friendly front-end commands on top of the command
    Stephen> line primitives.

That probably largely explains the philosophy of the lead developer
(also an Emacs/LISP fan).
-- 
Brian May <bam@snoopy.apana.org.au>