[MonoDevelop] Search for parent changelogs

Lluis Sanchez lluis at ximian.com
Sat Jun 23 11:39:38 EDT 2007

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.

> > 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 mailing list