File groups

[Jan Hudec]

On Thu, Jan 26, 2006 at 09:53:20 +0100, Vincent LADEUIL wrote:
> >>>>> "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.

I agree. Besides I don't really see any benefit to this.

>     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.

Commits are tree-wide, so it won't actually matter. But I don't think
it's actually useful.

>     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.

This however could be really useful.

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

They don't. They forbid commit on which tests - defined by the project
itself - fail. Besides they run on the local machine anyway, so it's
easy to turn them off.

> 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.

The users should be allowed to do anything they want. And should be
allowed to deny themselves to do some things. The way to define those
things is beyond scope of bzr - bzr just provides the hooks to put it
in.

Due to distributed nature of bzr they won't be able to enforce it on
anyone else anyway.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060126/63629d57/attachment.pgp