Hi,
This would probably require that there are actually -two-
databases: a local database that acts like a journaling
filesystem and remembers all file renames deletions props etc.,
and the central database on the server.
A 'commit' would then sync/merge/transmit the local
database+data with the database on the server.
on the long run, what we all want could be the combination
of a journaling filesystem with a version control backing store,
and a feature to synchronize such a -local- database with
the central server database. extending this with transfer
methods borrowed from 'rsync' could maybe produce the
' most wanted (programmers-) filesystem ' :-)
in the meantime, 'standard filesystem' based revision control is
probably 'just another workaround before we get the real thing'.
:-)
====
c.a.t.
Walter White wrote:
> Hi All,
>
> I was thinking about how subversion or any RCS could be improved. If
> subversion implemented a filesystem or daemon that can be configured to
run
> on a directory or filesystem only, then the user wouldn't have to worry
> about commiting changes or using the subversion commands to move and
rename
> files. The daemon or filesystem will pick up these commands and make
proper
> changes to the repository. I think this would have practical use on both
> servers and desktops use since this would remove the need for using the
> subversion commands directly. The extra layer of abstraction will work
> since it is just another filter that would make life easier and RCS more
> automated. Basically, I want something that the user does not have to
> constantly interact with, and this can be a simple extension to subversion
> that would allow people to use the automated version or the manual one.
>
>
> Walter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 4 16:06:11 2004