> Rik van Riel a écrit :
> >
> > On Mon, 23 Jul 2001, Larry McVoy wrote:
> >
> > > b) Filesystem support for SCM is really a flawed approach.
> >
> > Agreed. I mean, how can you cleanly group changesets and
> > versions with a filesystem level "transparent" SCM ?
>
> With label !
>
> In my initial post, i have explain that labels are used to
> identify individual files AND are also uses to select for
> each files of a set, one version (= select a configuration).
> It works !
.. and essentially you've re-created Rational's ClearCase implementation.
The problem becomes: how will you specify that label for file version
selection? Will it be part of the filename? Will it be implied in a
configuration specificier (config spec)? Will that config spec be global
to the system, local to the user or just that session? Will it be stored
in a file or part of the filesystems mount parameters?
These are the same problems Rational faced with ClearCase and it's mvfs.
To maintain a config spec design you'll need essentially a database to
contain the labels and their relationship to a given version & branch of
a particular file. So, suddenly it's not just a filesystem, it's now a
database with external chunks of data.
> > The goal of an SCM is to _manage_ versions and changesets,
> > if it doesn't do that we're back at CVS's "every file its
> > own versioning and to hell with manageability" ...
Really, the whole of the problem needs to be reviewed, not just the
individual parts. I seem to recall someone implementing a filesystem
that stored the files in a Postgres database that did versioning of files
in a simple way. I thought that was rather novel, at the time. You
really need to think out the unifying mechanism first. The storage of
versions of each file will be an end result. Think more about how the
user will actually use it and manipulate the selection.
> versioning is yet a first step.
>
> j.
-- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/