[MonoDevelop] Search for parent changelogs
Jacob Ilsø Christensen
jacobilsoe at gmail.com
Sat Jun 23 11:55:10 EDT 2007
On 6/23/07, Lluis Sanchez <lluis at ximian.com> wrote:
> El ds 23 de 06 del 2007 a les 17:20 +0200, en/na Jacob Ilsø Christensen
> va escriure:
> > Hi. Thanks a lot for the input. I have a few comments below.
> > On 6/23/07, Lluis Sanchez <lluis at ximian.com> wrote:
> > > Hi,
> > >
> > > The question here is where do you start looking for the "closest"
> > > ChangeLog. For example, if I run Commit in the monodevelop/src/Core
> > > directory, and I have changes in
> > > monodevelop/src/Core/MonoDevelop.Projects and
> > > monodevelop/src/Core/MonoDevelop.Ide, the changes in each assembly
> > > should be logged in their corresponding ChangeLogs. That is, a single
> > > commit operation might change several ChangeLog files at the same time.
> > Yes, that needs to be supported.
> > > If we want to improve the add-in, so it can automatically create
> > > ChangeLogs, it has to be done in a way that doesn't force the user to
> > > make a decision at every commit. The current behavior is very simple: if
> > > the commit directory has a ChangeLog file, it will be updated. If there
> > > isn't one, it shows a bold red message with a warning saying that no
> > > ChangeLog entries will be written.
> > >
> > > This behavior is clearly based on the commit policy we have in MD, on
> > > which there is a single ChangeLog for each assembly, and commits should
> > > be done independently for each assembly.
> > I usually used svnci to commit for several assemblies at a time, if
> > changes in one assembly break another assembly. But as you describe
> > above, this will be possible if we support multiple ChangeLog updates.
> > > In this context, creating a
> > > ChangeLog file when none is found is not what we want. In MD, creating
> > > new ChangeLog files is very uncommon, since it's only done when adding
> > > new assemblies. So giving the choice of creating a ChangeLog at every
> > > commit is not good.
> > >
> > > The problem, of course, is that not all projects follows MD's commit
> > > policy. For example, in the Mono libraries, every directory must have
> > > its own ChangeLog file. So, in this project it *does* make sense to
> > > create a ChangeLog file when none is found. For example, if I'm
> > > committing a change in mcs/class/corlib/System, and there isn't a
> > > ChangeLog there, the add-in should create a new one ChangeLog, even when
> > > the parent directory 'corlib' does have a ChangeLog. That is, I
> > > shouldn't even have the option of selecting the parent directory, since
> > > it's against the project policy.
> > >
> > > So, I think that the solution would be to add support for different
> > > commit policies, and allow choosing the commit policy for every project.
> > > Here are some policies we could support:
> > >
> > > * Create a ChangeLog in the project root directory, and in any
> > > subdirectory until N levels, where N would be a configurable
> > > value. For MonoDevelop, N would be 0. Other projects might want
> > > to have ChangeLogs only in the first level of subdirectories, so
> > > N would be 1, and so on.
> > Very flexible indeed. We might start out with having N equal to 0 for
> > the first version. :-)
> Ok :)
> > > * Create a ChangeLog in every directory of the project. That would
> > > be Mono's policy.
> > > * Never automatically create ChangeLogs. Update only ChangeLogs
> > > which exist.
> > > * More ideas welcome.
> > Just a question. Is the VersionControl aware of the link between
> > projects and files? I mean, when one wants to commit a bunch of files,
> > we need to check what project each one belongs to to determine what
> > ChangeLog strategy should be applied when committing that particular
> > file.
> This should be done by the ChangeLog add-in. You know the files, so you
> can know what projects they belong to, and check the policy there.
Yes, I know the file names, but how do I determine what project they
belong to? Any documentation on that? Also (in theory) a file could
belong to several projects, could it not?
> > > So, after a policy is set for a project, the user doing a commit will
> > > never have to make a choice. The add-in will be able to find the
> > > ChangeLog or create it when necessary, following the configured policy.
> > > When a suitable ChangeLog can't be found or created, the add-in can just
> > > show a very visible warning message, like it does now.
> > The add-in should support updating of multiple ChangeLogs, right?
> Yes, it could show a list of all ChangeLog files being updated, and a
> warning message if there is some file for which no ChangeLog could be
More information about the Monodevelop-list