octave-maintainers
[Top][All Lists]
Advanced

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

Re: very small packages - merge into general/miscelleneous or move into


From: Olaf Till
Subject: Re: very small packages - merge into general/miscelleneous or move into core
Date: Sat, 1 Feb 2014 19:47:59 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Jan 31, 2014 at 08:41:06AM +0100, Olaf Till wrote:
> On Thu, Jan 30, 2014 at 03:21:40PM -0500, John W. Eaton wrote:
> > On 01/30/2014 04:48 AM, Olaf Till wrote:
> > >On Tue, Jan 28, 2014 at 11:41:34PM +0000, Carnë Draug wrote:
> > >><snip>
> > >>Is there any way to move a file between two
> > >>different hg repositories, while keeping its history?
> > >
> > >Although my knowledge of Mercurial is not comprehensive, I'd think
> > >that moving a history of commits between different repositories is not
> > >possible, due to the concept. Think of file name clashes, e.g., or
> > >even contradictions in the motivation of patches (e.g. if a function
> > >was added although an equivalent function was already present in the
> > >other repository).
> > 
> > Nothing prevents merging unrelated repositories:
> > 
> >   http://mercurial.selenic.com/wiki/MergingUnrelatedRepositories
> > 
> > Although that page says it is not recommended, it could make perfect
> > sense if you are merging two completely separate things to form a
> > new combined work.
> > 
> > In any case, why should merging history be prevented just because
> > some conflicts might arise?  With independent development going on,
> > conflicts can happen at any time, even for changes that begin with a
> > common ancestor.
> > 
> > However, moving a single file and only the changes for that one file
> > is a bit harder since changesets may affect more than one file.  So
> > you might have to dig out the series of individual diffs for a
> > particular file and apply them one at a time, creating a new series
> > of changesets in the process.
> 
> I'll give it a try and discuss the result before pushing.

I just didn't think of the obvious possibility that both histories are
kept as seperate branches of a package up to the merge.

What I've done as a test:

1. Converted needed files of "general" (parcellfun.m, pararrayfun.m,
   parcellfun_opts.m, chunk_parcellfun.m, fsave.cc, fload.cc,
   __exit__.cc) to Mercurial with 'hg convert --filemap ...'. This
   only includes the applicable (36) changesets and modifies these
   changesets to apply only to the selected files.

2. As explained in the link given by JWE, pulled the converted part of
   "general" into "parallel" and merged. So the history of the
   converted part of "general" is conserved as a separate branch of
   "parallel" up to the merge.

Luckily, no files except the converted ones are named explicitely in
the commit messages of the converted changesets (so no need to decide
whether the commit messages should be edited for this reason).

I thought of modifying the commit messages anyway, including a line
like "[changeset converted from package general]", to clarify just
this and to indicate that the changesets are possibly modified
(unrelated files dropped). But now I think even this is not necessary,
because the separate branch is named "general" and in the commit
message of the merge I can note that this is a merge with a _part_ of
package "general" and list the files included from "general".

If you agree to that, I'll push it. Afterwards, I'll do the necessary
reorganization (Makefile, documentation, dropping one of the two exit
functions, clarifying that fsave/fload are only for use on the local
machine).

Olaf

-- 
public key id EAFE0591, e.g. on x-hkp://pool.sks-keyservers.net

Attachment: signature.asc
Description: Digital signature


reply via email to

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