[Prophesy] Re: Improved string transformation

[Rasmus Andersen]

On Sun, Jun 02, 2002 at 01:58:38AM +0200, Daniel Phillips wrote:
> > And I think
> > that this is one of the cardinal weak points in CVS, and thusly
> > one where we should aim for being strong.
> > 
> > But I have no good ideas on how to handle this and still get
> > transparency.
> 
> Ah, I see what you're getting at.  OK, we are not going to rely *only* on the 
> transparent editing interface, but on other means of feeding the scm as well, 
> to supply the other needed information, which will be kept with the deltas in 
> the database.  I envision a graphical user interface running while the scm is 
> running, which gives a view of the source tree and lets you walk over it to 
> add comments, tags etc.  Of course we will provide a command shell way of 
> doing these things as well.

I think my point is that at the lowest level of this, at the FS level,
can we attach meaning (and comments) to (FS) operations? Some people
obsessively save their buffers after each little edit and it would
seem that a revision history reflecting this would not be very helpful.

On the other hand, if the SCM merely uses the FS operations to gather
knowledge about changed objects[1], then the user would still have to
do a explicit 'commit' to make a delta(?) and attach comments. Which
isn't that far from what you would do anyway without the magic FS.

Or am I missing something?

> 
> While we're on that topic, we want to make the SCM an embeddable object, so 
> that both the gui and the command interface simply invoke the scm methods.  I 
> guess we can rely on Python to handle that aspect for us, and so not get 
> stuck in some sticky tarpit like Corba, or COM, or building our own object 
> embedding protocol.

I agree strongly on the embeddable part. And python play nicely with
embedded C. And the other way around (being embedded) too.

> 
> Speaking of gui, I think Glade should be the tool, the only realistic 
> alternative being QT/KDE, and while I do like the latter a lot in terms of 
> sheer usability, I also like the faster startup and lower resource usage of 
> GTK.  Furthermore I'm familiar with Glade, and I like the idea of being able 
> to separate out the interface definition into an XML object.
> 
> So, now I'm going to take a quick look at how Glade and Python play together.

I am a GUI newbie so if you have experience, you lead the way.


[1] We haven't discussed the basic object in the SCM. Is it a file?
A function? A line (of code)? I could see some nice things coming
from having smaller granularity than the file one, but since we
are aiming at having 'loose' dependencies in the SCM I think we
will get those anyway.

Rasmus