[Prophesy] Re: Improved string transformation

[Rasmus Andersen]

On Mon, Jun 03, 2002 at 09:44:01AM +0200, Daniel Phillips wrote:
> > 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?
> 
> No, good point, and it's one I've thought about, I just neglected to say 
> anything about it.  My thinking is that the scm will normally save a 
> transform against a file every time the file is written to for whatever 
> reason, but when you commit, those transforms are collapsed into a single 
> transform.  So until you do the commit, you have file-level undo, if you want 
> it.  It's just easy to provide this, so why not?  We can also provide an 
> option to leave those transformed un-composed in the database, which will eat 
> a lot of space a probably be useless, but it might be interesting to 
> somebody, and it's easy to do, so again, why not?

OK then. This would seem to be a reasonable middle ground. If it wasn't
for you having some FS experience already, I would probably think the
magic FS way too complex for what it is buying us/the user.

Can we do this without a kernel patch? A kernel patch may be a bit
too much for many that just wants to dip their toes.

> > 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.
> 
[snip things about having files as basic versioning object]
> 
> A practical question is whether we're going to version directories.  I 
> mentioned the idea that each file object would have an id (which is 
> universally unique) and the name of the file would be metadata associated 
> with the object (i.e., an attribute of the object).  However, we will need to 
> look up files rapidly by name, for example, when a file is changed and a 
> transform needs to be recorded against it in the database.  This can of 
> course be handled efficiently by appropriate use of database indexing.
> 
> We may sometimes want to traverse the database in directory order, perhaps 
> when producing a diff between two tree versions.  Does this mean we want to 
> record directories as objects?  I don't know yet.  It may be enough just to 
> compute the directories on the fly.

Another related thing is, how do we group changes to achieve logically
connected changes, aka changesets in BK terminology? I guess that would
be by explicit operations in the GUI/command line thingie operating on
deltas?

> 
> Drifting further in that direction, the question arises of how much 
> filesystem structure we want to support in the scm.  Do we want to support 
> symlinks?  I think we do.  Hard links?  Good question.  Device nodes?  Hmm.
> If we support all of the above, then what we have is more general than a 
> source code versioning system, it's actually a versioning filesystem.  That's 
> something to think about.  However, right now I'll be satisfied aiming at 
> something with more modest goals.

Rik van Riel and Larry had some thought about using magic FS's to the
job a while back... <googling> Here we go. Its kinda sketchy but some
stuff can be had:

http://search.luky.org/linux-kernel.2001/msg25061.html

Rasmus