Hi, On Sat, Aug 30, 2008 at 10:55:37PM +0200, Arne Babenhauserheide wrote: > Am Samstag 30 August 2008 02:55:25 schrieb [EMAIL PROTECTED]:
> > 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-
