Re: GWindows and David Botton

[Stephen Leake <stephen_leake@acm.org>]

Brian May <bam@snoopy.apana.org.au> writes:

> >>>>> "Stephen" == Stephen Leake <stephen_leake@acm.org> writes:
> 
>     Stephen> Because that's what SourceForge supports. We need a
>     Stephen> server that won't go away, that many independent
>     Stephen> developers can use.
> 
> Any site that allows HTTP access will work with TLA, although in
> read-only access.
> 
> Any site that allows sftp access will work with TLA, not sure if
> sourceforge does or not.

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

>     Stephen> Is there an available, robustly supported server that provides
>     Stephen> TLA/arch access, like SourceForge does for CVS?
> 
> Yes, there are. For example there is http://alioth.debian.org/, run by
> Debian, see http://arch.debian.org/ for details. I believe alioth also
> supports subversion. There are others available, I can't think of them
> off-hand.

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

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

>     >> * GPG signed repository updates (could be good especially important
>     >> when writing critical software; makes it harder for intruders to
>     >> tamper with the archive undetected).
> 
>     Stephen> I'm not sure that's much better than ssh access.
> 
> ssh solves a different problem; ssh is transport layer, this is when
> it is stored on disk.
> 
> So, when committing a changeset, I sign the changeset too. Now if
> somebody managed to get write access to the repository, and changed it
> to make it look like I inserted malicious code, the signature would no
> longer match, and it would be clear the archive is corrupt.

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

> To be fair, it does have some disadvantages:
> 
> * It requires a new mind set, and old CVS concepts have to be
>   forgotten and relearnt.

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

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

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

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

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

>   Dealing with rejects by looking at a reject file from patch takes
>   a bit of getting use to (the developers have good reasons for
>   doing it this way, they say it makes it easier to manage conflicts
>   this way).

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

> * 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).

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

-- 
-- Stephe