Re: Authoring a versioning plugin

[David Masover <ninja@slaphack.com>]

Bedros Hanounik wrote:
> I think versioning plugin is a great idea and I bet there're many people 
> like me waiting for such a plugin. However, I have few questions;
> 
> what happens when I delete a file? should I loose all history of the 
> file with such action?

Depends.  Delete has always been a modification of the directory, not 
the file.  So, if you were versioning an entire directory tree 
(recursively, of course), then deleting a single file within that tree 
would be a modification to its parent directory.  Until the 
changelog/history/old versions of the parent directory all disappear, 
there will be a link to the file, meaning the file still behaves exactly 
as it always did, it's just that instead of only being linked to in

foo/bar

it's now in

foo/.../version/1234/bar

[...]

> if you store all the history in  a sub direcotry let's say .rev and make 
> it generic (and hence visible) to everyone, the above problems will go 
> away.

Only now you have some new problems:

What if someone wants to make a .rev for something else?  '...' was 
carefully selected, and is still debated.  Now you're suggesting each 
plugin be able to have its own file/directory in every normal directory?

NO.  Will not work.

What might work is creating a '.metadata-archive' directory, which has 
hardlinks to everything tar is allowed to backup from '...' -- that way, 
we only need to come up with one more unique name than we already have.

Technically, not even that -- we could hide a directory with any name we 
like inside '...', and let tar archive '...', but not, say, '.../notar', 
but that's a hassle for users.  Anyone have a better name for 
'.metadata-archive', though?

You also have another problem:  You've just broken 'rm -r' and 'mv' 
across partitions/devices.  Consider:  Am I allowed to remove 
'.metadata-archive'?  If yes, then what happens when I look for it 
again?  Is it magically still there?  And if no, how am I supposed to 
ever be able to rmdir a directory that's technically not empty?  Should 
that just magically work?

I suspect that we'd be fine if we just say that removing it should 
pretend to work (return an OK status), and rmdir should actually work, 
but it should always show up in the directory listing, because I can't 
think of why a program would step through the directory listing, 
unlinking each file, and then get another directory listing, to make 
sure they're all gone, before it tried 'rmdir'-ing the directory.  It 
makes no sense -- you try to 'rmdir', and you complain to the user if 
"directory not empty" because someone stuck a new file in the dir while 
you were trying to delete it.

> for example filename.ext deltas could be stored in  .rev/filename- 
> rev-date-time.delta with base rev in .rev/filename-rev-date-time.ext

I don't like your semantics.  I just don't.

It makes sense to use file extensions for fibration, because you can 
guess that '.o' files are similar to each other.  Same with '.c' files. 
  But fibration is completely transparent, and just affects performance, 
so it's ok to guess there.

When it comes to actually affecting semantics, file extensions have 
always been irrelevant except to programs that care, and those programs 
only care about their own extensions.

For instance, say I have

foo.tar.bz2

Obviously, this way looks bad:

foo.tar-rev-date-time.delta
foo.tar-rev-date-time.bz2

So do we do it this way?

foo-rev-date-time.delta
foo-rev-date-time.tar.bz2

No, because then what if you have this?

foo.01.12.2006.tar.bz2

Obviously, this is wrong:

foo-rev-date-time.delta
foo-rev-date-time.01.12.2006.tar.bz2

And this is just as wrong as it was before:

foo.01.12.2006.tar-rev-date-time.delta
foo.01.12.2006.tar-rev-date-time.bz2

And for that matter, what if I have these?

foo.tbz2
foo.zip

Both become foo.delta.

And just a minor thing, but you're also making the limit on filenames 
just that much more restrictive.

Instead, I suggest we do it this way:
foo/.../version/<rev>

with symlinks to some handy versions of
foo/.../version/<date>
foo/.../version/<time>

This should also work if foo is a directory.  So to actually publish a 
given revision, you do

tar -cjSf foo-1234.tar.bz2 foo/.../1234

Now, what about forking?  If we had good copy-on-write support, we could 
just do something like

cp --cow foo/.../1234 foo-fork

Obviously, this would use the same underlying mechanism of copy-on-write 
that is used for the versioning system, so there's no need for the 
system itself to know about forks.

What about merges?  I don't know, but my knowledge of existing 
versioning systems is pretty limited...