Re: GWindows and David Botton

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

>>>>> "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.

    Stephen> CVS may be old, but it does the job well enough.

It is also the most popular.

    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.

    >> * allows for renaming/moving files/directories, while maintaining full
    >> history, without resorting to ugly hacks.

    Stephen> That would be nice.

Yes, definitely. It means you can commit your project straight away,
even though you may plan to completely redesign the file system
layout.

There are several ways this can be done, one way is to insert a
special tag into every file. This means to move a file, you just move
it. TLA will pick it up automatically.

Some people don't like this approach, so other methods are
available. I use the explicit method, which means every file has a
separate .id file, in the .arch-ids directory, which contains a unique
identifier for the file. If you move a file, you move its id at the
same time (I use Unix aliases to help me with this), so tla knows what
has happened.

    >> * distributed repositories (meaning I can create my own repository,
    >> commit to it, and synchronise upstream changes, even if I don't have
    >> write access to the "official" server)

    Stephen> That's also nice, if it works well.

Its a future I haven't used extensively, but on the rare occasion I do
use it, it works pretty well.

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

    >> and this newsgroup... However, I use it for all my Ada software ;-).

    Stephen> Ok, that's a good recommendation.

;-)

To be fair, it does have some disadvantages:

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

* It was built by a developer who hates Windows. As such, Windows
  support is still not official. There are unofficial versions
  versions for Windows, some people have complained of poor
  performance and other issues. For example, Unix supports a
  repository with two files "README" and "readme", but if you try to
  use this repository on windows, you will get unpredictable results,
  as Windows is case-insensitive.

  However, I have used the cygwin version, it seems to work fine, at
  least for my small projects. A native windows version is also
  available.

* The lead developer likes command line tools, e.g. patch, reject
  files, etc. Some people may not like the absence of a GUI
  interface. 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).

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

I think all of these issues are being worked on, I am not exactly
keeping up-to-date with the latest developments (due to time
constraints). I could imagine some of these points might be show
stoppers for some people, it depends on the developers who will be
using it, and what it is for, I guess.

Then there is also subversion. I realize the arch developers dislike
subversion, saying some of the design decisions are really bad,
doesn't support distributed repositories, archive format is ugly, etc,
but it does work well for a number of projects, and doesn't have some
of the limitations mentioned above.

Somebody once made the analogy that subversion like a newer version of
CVS, TLA is a complete rewrite from scratch.
-- 
Brian May <bam@snoopy.apana.org.au>