[MonoDevelop] Search for parent changelogs

Sat Jun 23 11:20:59 EDT 2007

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

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

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

/Jacob

>
> Lluis.
>
> El ds 23 de 06 del 2007 a les 09:39 +0200, en/na Jacob Ilsø Christensen
> va escriure:
> > On 6/22/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > On 6/22/07, Marcos Marín <marcosmarin at gmail.com> wrote:
> > > > Re: [MonoDevelop] Search for parent changelogs
> > > >
> > > > The problem I see with this radio button approach is, what if there are n
> > > > levels in the tree? for example
> > > > MD_ROOT/Extras/BooBinding
> > > >
> > > > you might have a ChangeLog in MD_ROOT, Extras and BooBinding.
> > >
> > > Yes, my first approach just selects the "closest" ChangeLog.
> > >
> > > >
> > > > What if instead there was a "Select ChangeLog" button and this would bring
> > > > up a dialog with a List of ChangeLogs, one for each level in the tree, and a
> > > > small (will be created) next to each that does not exist?
> > >
> > > Yes, this will indeed open up for more choices. So:
> > >
> > > A label and a button:
> > >
> > > The label will state what ChangeLog is currently chosen and will
> > > default to the local one.
> > > The button will bring up a dialog allowing the user to choose between
> > > ChangeLogs (existing  and to be created) in each directory upwards.
> >
> > Here are some new screenshots. The "Select ChangeLog" button will
> > bring up a list of ChangeLogs, one for each directory upwards. Also
> > one will be able to change the default behaviour from always
> > using/creating the local one to using a parent ChangeLog if there is
> > one.
> >
> > Does this look better?
> >
> > >
> > > Also a per project/solution configuration could then define whether
> > > the default ChangeLog should always be the local (existing or to be
> > > created) or the closest existing one (if any).
> > >
> > > > Just my two cents.
> > > >
> > > >
> > > > On 6/22/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > > >
> > > > > Hi.
> > > > >
> > > > > Just to get some feedback I drafted up a quick GUI.
> > > > >
> > > > > I see three situations:
> > > > >
> > > > > * There is a local ChangeLog (local.png)
> > > > > * There is no local ChangeLog but there is a parent ChangeLog
> > > > > (nolocal_parent.png)
> > > > > * There is neither a local ChangeLog nor a parent ChangeLog
> > > > > (nolocal_noparent.png)
> > > > >
> > > > > A per project/solution configuration could then be used to decide the
> > > > > default radio button.
> > > > >
> > > > > Does this make sense or should the GUI be structured differently?
> > > > >
> > > > > Regards,
> > > > > Jacob
> > > > >
> > > > > On 6/22/07, Rafael Teixeira <monoman at gmail.com> wrote:
> > > > > > I would prefer to have it present the choice of using the parent
> > > > > > changelog or creating one in some place along the path.
> > > > > >
> > > > > > Also a solution/project option could help set the preferred policy, as
> > > > > > some groups just prefer a top changelog, and others like
> > > > > > mono/monodevelop, prefer per directory ones, and some have both
> > > > > > things.
> > > > > >
> > > > > > :)
> > > > > >
> > > > > > On 6/22/07, Jacob Ilsø Christensen <jacobilsoe at gmail.com> wrote:
> > > > > > > Hi.
> > > > > > >
> > > > > > > The attached patch changes the ChangeLogAddIn behaviour such that if a
> > > > > > > ChangeLog is not found in the current directory, parent directories
> > > > > > > are searched.
> > > > > > >
> > > > > > > Is this ok to commit or is it a bad idea?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Jacob
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > Monodevelop-list mailing list
> > > > > > > Monodevelop-list at lists.ximian.com
> > > > > > >
> > > > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Rafael "Monoman" Teixeira
> > > > > > ---------------------------------------
> > > > > > "I myself am made entirely of flaws, stitched together with good
> > > > intentions."
> > > > > > Augusten Burroughs
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Monodevelop-list mailing list
> > > > > Monodevelop-list at lists.ximian.com
> > > > >
> > > > http://lists.ximian.com/mailman/listinfo/monodevelop-list
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > _______________________________________________
> > Monodevelop-list mailing list
> > Monodevelop-list at lists.ximian.com
> > http://lists.ximian.com/mailman/listinfo/monodevelop-list
>
>