File groups

[Vincent LADEUIL]

>>>>> "Martin" == Martin Pool <mbp at sourcefrog.net> writes:

    Martin> On 24 Jan 2006, Aaron Bentley
    Martin> <aaron.bentley at utoronto.ca> wrote:
    >> The other idea from PyGTA was file groups.  The idea that
    >> for some projects, a group of files may be a semantic
    >> unit.  (foo.c, foo.h being an example) The idea was that
    >> commits (and possibly other operations) must always be
    >> applied to both files, not one.  We didn't discuss what to
    >> do if the user tried to commit only one, but the two
    >> obvious options are: 1. commit both 2. error out


>>>>> "John" == John Arbash Meinel <john at arbash-meinel.com> writes:

    John> An interesting idea. But I wonder...  Wouldn't you
    John> really just want full dependency tracking. Because some
    John> other file *uses* the functionality provided by that .h
    John> file. So they should be updated as well.

    John> Ultimately I think this would be very complicated to
    John> get a nice interface to, but it might be worth keeping
    John> in the back of our heads.

That should not be part of bzr IMHO.

    John> Using scons on a new project and integrating it with
    John> the bzr TestSuite stuff can be really cool. So it only
    John> runs the tests if the files involved are modified, or
    John> if the tests themselves change. It's really large
    John> grained right now, where each library has its own
    John> tests.

    John> Along with my version-info plugin, I have scons rebuild
    John> the verison files when the tree changes, which rebuilds
    John> the objects and the libraries.

    John> Anyway, I digressed because scons has good dependency
    John> tracking.

I  don't think you  digress, the  purpose of  the File  groups as
presented is a dependency issue.

I think that bzr do  not have to track dependencies. It's obvious
to me that change sets  will generally modify a dependency-related
set  of  files,  but  there  exist  a  lot  of  cases  where  the
modifications span several such groups or modify the dependencies
themselves. 

Issuing  an   error  when  such  changes  occurs   is  clearly  a
show-stopper.

Committing  all members  of the  group when  only one  change will
generate a lot of empty commits.

    Martin>  That's an  interesting  idea.  Another  way to  keep
    Martin> things in track is for a pre-commit hook to write out
    Martin>  the  in-memory tree  that  will  be  committed to  a
    Martin> temporary  directory and  run a check  in there  - so
    Martin> that should trap  committing source without a header,
    Martin> etc.

I can't  even agree  on pre-commit if  they risk to  forbid valid
modifications violating the dependency rules.

I think other tools should be used with their own set of datas to
handle the dependencies. Of course those data should be committed
too, but it's another problem.

And don't  get me wrong, I'm  a strong supporter  of well managed
dependencies, but it's outside the scope of bzr IMHO.

The  basics of  SCM is:  who did  what when.  That does  not (and
should not) enforce any definition of "what". If I want to commit
garbage, I should be able to do so as long as anybody can see the
garbage and decide what to do with it.

Now, it may  possible to imagine policies implemented  via pre or
post  commit  hooks but  I  fear  that  they  will  not  authorize
sufficient freedom.

              Vincent