octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: feature question / request


From: Paul R
Subject: Re: feature question / request
Date: Thu, 21 Aug 2008 09:37:17 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Hi Jaroslav,

On Thu, 21 Aug 2008 09:09:35 +0200, "Jaroslav Hajek" <address@hidden> said:
Jaroslav> Hello, first of all, I would like to thank all involved
Jaroslav> developers for Mercurial, which does an excellent job
Jaroslav> helping us to develop Octave. My question is: We use
Jaroslav> a number of ChangeLog files in the source tree, that simply
Jaroslav> collect short descriptions of committed changes. (Not
Jaroslav> strictly necessary, but helpful). These ChangeLog files are,
Jaroslav> however, a constant hassle when applying patches made
Jaroslav> against non-tip revision or transplanting changesets into
Jaroslav> stable branches. They often fail to patch due to mismatching
Jaroslav> previous entry.

Jaroslav> Question: Is there any existing means how to solve this
Jaroslav> problem in Mercurial? If not (or if it's complicated),
Jaroslav> I think that a relatively simple solution is to somehow
Jaroslav> instruct Mercurial to use zero lines of context when
Jaroslav> creating diffs for files matching a specific pattern
Jaroslav> (*ChangeLog). Since entries are (almost) always prepended to
Jaroslav> the file, that would make the patches apply smoothly and do
Jaroslav> exactly what we want them to (prepend entries in the order
Jaroslav> they appear in a repo/branch). The option could simply be
Jaroslav> switched off when making a more complicated change to the
Jaroslav> ChangeLog file. I don't think this is currently possible in
Jaroslav> Mercurial (if I'm mistaken, please enlighten me), but
Jaroslav> perhaps something along these lines would make a useful
Jaroslav> feature.

Mercurial can use whatever file diff/merge program you want. I also
often face this problem, and I've alway wanted to to something like
a wrapper around common merging processes, that would first look for
a cookie in the first lines of the file to merge. The cookie could be
something like :
# merge: stack_above
or
# merge: stack_below
so that buglist or TODO_list get automatically merged.

Waiting for the magic solution, we use an emacs Org file, with one
toplevel node per branch. By adding consistant text context for each
branch, it suppress conflicts.

I don't know how distributed bug trackers works, though. It can be
a source of information.

-- 
  Paul


reply via email to

[Prev in Thread] Current Thread [Next in Thread]