[Nix-dev] Re: Merging fix-style branch into the trunk ?

Nicolas Pierron nicolas.b.pierron at gmail.com
Thu Apr 9 19:52:21 CEST 2009


Hi Nixers,

This mail is just an history feedback for future git cherry-picks
problems and how this has solved the history issue of subversion.

The issue raised by Ludovic was that the history is damaged due to the
use of "git cherrypick" which does not reproduce correctly the
cherry-picking action into the subversion repository.  Therefore the
subversion history is broken and the command "svn log -g" does not
follow original commit sources.

With the help of Eelco, we have learned that subversion 1.5 handles
merges and sub-set merges:

svn merge ../../trunk # merge the trunk ( ] fork .. HEAD ] ) into the
current branch
svn merge ../../trunk @ REV # merge the trunk ( ] fork .. REV ] ) into
the current branch
svn merge -r REV1:REV2 ../../trunk # merge the trunk ( ] REV1 .. REV2
] ) into the current branch

Therefore the cherry-picking action can be performed in subversion as:

svn merge -r REV-1:REV ../../trunk

or

svn merge -c REV ../../trunk

This command have been helpful to restore the subversion history.  A
new branch (with a name matching the goal of the fix-style branch)
named "modular-nixos" has been created to restore the time line inside
subversion.

This branch has been copied from fix-style branch before its first
merge.  Then each merge with the trunk is marked in the branch history
as

* Synced with trunk @ /REV/

where /REV/ is the last commit included in the merge.  Theses merges
correspond to series of cherry-picks done either by Marc Weber or by
me.  These merge results are extracted from the fix-style branch at
the corresponding history.  So the branch should be identical and the
cherry-picks operations are still available in the fix-style branch
(useful for blaming after a merge because the conversion may not be
straight forward).

Each commit made inside the fix-style branch are marked as:

* Synced with branches/fix-style @ /REV/

In this case the /REV/ number is the last commit merged but the first
commit is the last cherry-pick of the trunk (not included).  Thus
commit made in the fix-style branch are keeping there original
authors.

To conclude, the modular-nixos branch conserve the original authors of
commits and solve Ludovic's issue.  This branch is now synchronized
with the trunk at the revision 14801 (not the last one).

The modular-nixos branch will be eligible for a merge soon (options in
the manual, dependencies on older nix versions, ...).
If you are against this union, you should raise your mail to explain us why.


On Mon, Feb 23, 2009 at 17:41, Nicolas Pierron
<nicolas.b.pierron at gmail.com> wrote:
> Hi Nixers,
>
> I have started the fix-style branch a while ago because this may have
> created some problems in the main line.  The goal of this branch was
> to prove us that NixOS can be modular and easier to learn/extend with
> only one writing coming from the computer configuration syntax.  This
> goal of this mail is to ask you if you about complains against merging
> this branch into the main line.
>
> The previous evaluation system had the following problems:
> 1/ Users have to learn all Nix features to patch NixOS and to put
> their hands into the code in order to add services or primary
> features.
> 2/ NixOS features are spread over multiple files without any clear links.
>
> 1) This point has mainly be solved by introducing the function called
> "fixOptionSets" ( pkgs/lib/options.nix ).  This function allow users
> to write any extra configuration file which can be imported in his own
> configuration.  This enables devices & services specific
> configurations.  The other point behind this issue is related to
> non-extensible attribute which were mainly contained in
> system/system.nix
>
> 2) To exemplified this point, I will use the "at" daemon.
> - This is an upstart-job, so it as to be registered in
> upstart-jobs/default.nix.  As it is referred inside the previous file,
> it is put inside the upstart-jobs directory even if the "at" daemon is
> not directly related to the upstart-job configuration.
> - As this daemon may log under different user, it needs a file named
> /etc/pam.d/atd, which is generated by /etc/default.nix even if you are
> not using this daemon.
> - This service requires to have commands registered in the system path
> and to have some setuid programs.  So it has two line entries in
> system/system.nix to specify that.
> - Administrator may not want to enable such service, so they are allow
> to disable it with an option registered in system/options.nix
>
> On the other hand, as done in the fix-style branch, you have in
> upstart-jobs directory ( or in any other directory ) a file which
> contains the option declaration (interface), the job definition, the
> etc file and the setuid programs.  And a reference into
> system/options.nix because this file is part of the default choices
> offered by NixOS.
>
>
> This branch is mainly a proof of concept, so all jobs are not
> converted yet.  The experience was to check that NixOS system can be
> split in files which tackle specific issues.  There is more work
> waiting to be done on this, but we need some work force to do that.
> Hopefully, this work can be spread over time because this does not
> disturb everything.
>
> Main modifications made in this branch:
> - a few upstart-jobs conversion.
> - upstart-jobs/default.nix, etc/default.nix are configuration files.
> - extensible activation script.
> - system parts can be build in multiple files.
> - xserver handles multiple .. at the same time: windowsManager
> (compiz, wmii, ...), desktopManager (kde, kde 4, gnome, ...)
>
> Do you want me to push these modifications in the main line ?
>
> --
> Nicolas Pierron
> http://www.linkedin.com/in/nicolasbpierron
> - If you are doing something twice then you should try to do it once.
>



-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron
- If you are doing something twice then you should try to do it once.



More information about the nix-dev mailing list