Here it is. I also react to Gert's notes inline... Also is attached mine test build script.
Martin ----- Original Message ----- From: "Ian MacLean" <[EMAIL PROTECTED]> > >What do you think? Should I prepare patch for it? > sure. I'd like to see it. > > Ian ----- Original Message ----- From: "Gert Driesen" <[EMAIL PROTECTED]> > I definitely think we ought to consider using xml merging here, as the way > Martin implemented it will definitely cause problems, eg. when you change > the base directory in the redefined fileset, you can't just add the files of > redefined fileset to the original fileset definition ... Change base directory in fileset does problems. But more in xml merge than custom fileset merging... > when we can use raw xml merging, we could allow allow partial definition of > types, meaning that the original definition does not have to pass all > initialization rules as its only when actually referencing the type > definition (after possibly merging it with additional xml) that an instance > of the type will have to be created Done this way now :-) Or atleast very simmilarly... > should we also use the class naming guidelines for the enum field (eg. > RedefineMode.Replace instead of RedefineMode.replace instead), in order to > have it match our other enums (we could perhaps consider resolving them in a > case insensitive way)? Please, do it! It is not very nice to write redefinemode="Append" when whole script is in lowercase... > perhaps we should also rename the mode attribute to redefinemode, as that > name is more meaningful and there's less chance of it conflicting with an > existing attribute ... True and done. > Gert
test.build
Description: Binary data
DataTypeBase.cs.patch
Description: Binary data
FileSet.cs.patch
Description: Binary data
Project.cs.patch
Description: Binary data
Target.cs.patch
Description: Binary data
TaskContainer.cs.patch
Description: Binary data
PathScanner.cs.patch
Description: Binary data
