bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: An idea for versiont racking using translators


From: olafBuddenhagen
Subject: Re: An idea for versiont racking using translators
Date: Tue, 9 Sep 2008 09:48:56 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hi,

On Sat, Aug 30, 2008 at 10:55:37PM +0200, Arne Babenhauserheide wrote:
> Am Samstag 30 August 2008 02:55:25 schrieb olafBuddenhagen@gmx.net:

> > It would certainly be possible -- but what's the use? Version
> > control is not interactive, nor does it pass around komplex
> > structured data -- it's just the kind of use case for which the main
> > UNIX communication mechanisms (command line arguments and pipes)
> > were created, and consequently they work very nice here... And Git
> > demonstrates how to make good use of that :-)
> 
> A possible use is, that it could be done by any user tool, and it
> could use any version control system below that. 
> 
> It would provide a layer of abstraction for version tracking software. 
> 
> I could commit from any file system browser without having to change
> that browser. 
> 
> Imagine a multi-user system, where the administrator wants to provide
> a version tracked collaborative writing system, but all users can use
> exactly the system they want - they only have to have something which
> can operate on files, regardless if it's a GUI browser, a shell, or
> anything else. 

These are very good arguments -- and in fact the same ones that make me
argue for extensive use of filesystem interfaces in many contexts!

Yet I'm not convinced that version control really fits well into a
filesystem interface. Again, I do think that it would be very useful for
*browsing* the history; but I have very serious doubts about
comitting...

> > No, that's not possible. cp is really a rather dumb action: It reads
> > the data from the source files, and writes it to the destination
> > files. If the source files are managed by a translator, the
> > translator will only see that the files are read, but not where they
> > are written, or to what purpose...
> 
> Damn, but that's how it is... 

So, the next step is a mechanism for overloading UNIX commands?... ;-)

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]