[Prophesy] Diff to transform converter

[Daniel Phillips]

On Sunday 09 June 2002 21:08, Erica Douglass wrote:
> You're forgetting that you're going to have to translate between \n,
> \r\n (Windows), and \r (Macintosh) if you want full cross-platform
> compatibility.

Cross-platform compatibility isn't a goal, except that the end result
should work on all versions of Linux, not just Redhat or Debian.  If
somebody wants to port the code to other platforms, that's fine.

Somebody, sometime will no doubt want to pull some source files in
crlf format into the repository, and for that all we need is a
general-purpose filter:

   cat /c/sourcefile.c | crlf2unix >mytree/myfile.c

This follows from the overall design philosphy, which perhaps I
haven't expressed clearly enough, that a tree under management will
look and act just like a normal directory tree, except that any time
you create, change, move or delete a file in it, a daemon will
intercept the event and update a database accordingly.  Among other
things, this allows the use of a general purpose filter for such a
purpose as described above.

> This brings up a whole lot of questions, like:
> 
> -- What is your interface going to be?

The main interface is going to be a normal-looking filesystem as
described above.  This lets you get code into and out of the
repository, make changes to it and build binaries from it.  You can
use whatever tools you wish to for doing those things, so that part
of the interface is simple: whatever you are used to using.

Besides that, my immediate intention is to implement two commands:
tag and goto.  The first lets you give a name to the current
version, and the second alters the source text to be the same as
some previously tagged version.  Together these implement a simple
transport mechanism, which is the short-term goal I'm working
towards.  Other fancier interfaces can wait until we see how well
the transport mechanism actually works.

I should mention that my first concern is to make the single-user
interface very good, and at the same time, as transparent as
possible.  I feel that this is an area that has not been adequately
addressed in other source code management projects.  A tool should
make things easier for you, not harder.

> If it's web-based, it's easy to
> detect the browser and make assumptions.

A web interface isn't central.  When there is one, it's going to
be for reporting or download.  It would also be nice - very nice -
to have an lxr-style view of the code tree, with an incrementally
updating index.  I don't see using the browser to edit or manage
source files, the current state of browser technology just isn't
up to it.

> Cross-platform GUI... well,
> it's not as easy. If you want to force people to use Linux, you can make
> a Linux-only binary and a web-based client for people who aren't using
> Linux, but then you might have some pissed-off customers.

It's a stretch to call users of a free system 'customers'.  Anyone
who wants to use this system on some other platform than Linux can
get the source and do the port, or find a friend to do it.

> -- What DO your customers want? At what stage do you want to start
> pulling in user feedback? So far this list has mostly been "Daniel is
> cool because he can do a diff transform, and look, here's this nifty
> Python thing..." I usually start by asking the customer(s) what they
> want and designing from that spec. I think that is pretty much the norm
> in customer-centered development, which is definitely required if you
> want this project to actually succeed rather than to be a PET (penis
> enlargement tool).

Customer number one is me, and my main motivation is to come up with
something that saves time and does a more accurate job on certain
common tasks that have proved to be big time wasters for me.  One
such task is: preparation of patch sets, where each patch in the set
has to result in a system which builds and operates correctly.  To
date, I've handled that by maintaining multiple source trees and
diffing between them, but that is tedious and error prone, not to
mention consuming huge amounts of disk space.  Which brings me to
another big concern: saving disk space.  I see that on my laptop I
currently have xx gig in my src directory, and I have considerably
more on my server.  That's just too much.  Most of these source
trees are just minor variations on each other - experiments or
incremental versions.  I want to be able to go:

  goto linux-2.4.16; make install
  goto linux-2.4.19; make install

all in the same source tree.  (The new kbuild system, once it gets
into the tree, will help with this, as it - optionally - does not
pollute the source tree with build files.)

> I'm not trying to bash you, Daniel. I'm just questioning where this
> project is going. I would like to see a nice marketing-style spec with
> bullet points and customer needs analyses.
> 
> The question that everyone on this list should be thinking about is, "Is
> this a serious project that I am willing to invest my time in?" If so,
> we need a spec, not just C code.

The vast majority of successful open source projects start with some
working code that does something useful, so creating said working
code has to be the main focus at this point.  Besides, it's been fun
and interesting so far, and I do think it is going somewhere.

-- 
Daniel