Archive-Team
/
zfs
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 103 Wiki Activity

Update GIT documentation to describe the new DAC setup

This commit is contained in:
Brian Behlendorf 2008-11-20 16:54:29 -08:00
parent 34dc7c2f25
commit 9fc325737b
1 changed files with 30 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

54
GIT
View File

@ -8,16 +8,16 @@ Three major concerns were on our mind when setting up this project.
improvements and not get locked in to an old version of the code base. improvements and not get locked in to an old version of the code base.
o Secondly, we wanted to be able to easily manage our changes in terms o Secondly, we wanted to be able to easily manage our changes in terms
of a patch stack. This allows us to easily isolate specific changes of a patch stack or graph. This allows us to easily isolate specific
and push them upstream for inclusion. It also allows us to easily changes and push them upstream for inclusion. It also allows us to
update or drop specific changes based on what occurs upstream. easily update or drop specific changes based on what occurs upstream.
o Thirdly we needed our DVCS to be integrated with the management of this o Thirdly we needed our DVCS to be integrated with the management of this
patch stack. We have tried other methods in the past such as SVN+Quilt patch stack or graph. We have tried other methods in the past such as
but have found managing the patch stack becomes cumbersome. By using SVN+Quilt but have found managing the patch stack becomes cumbersome.
Git+TopGit to more tightly integrate our patch stack in to the repo By using Git+TopGit to more tightly integrate our patches in to the repo
we expect several benefits. One of the most important will be the we expect several benefits. One of the most important will be the
ability to easily work on the patch stack with a distributed developer ability to easily work on the patch's with a distributed development
team, additionally the repo can track patch history, and we can utilize team, additionally the repo can track patch history, and we can utilize
Git to merge patches and resolve conflicts. Git to merge patches and resolve conflicts.
@ -59,28 +59,34 @@ a summary command which shows all the branches and a brief summary for
each branch obtained from the .topmsg files. each branch obtained from the .topmsg files.
> tg summary > tg summary
0 t/LAST [PATCH] LAST 0 feature-branch [PATCH] feature-branch
t/feature-commit-cb [PATCH] zfs commit callbacks feature-commit-cb [PATCH] feature commit cb
t/fix-clock-wrap [PATCH] fix clock wrap feature-zap-cursor-to-key [PATCH] feature zap cursor to key
t/fix-dnode-cons [PATCH] fix dnode constructor
... ...
By convention all TopGit branches are prefixed with 't/', and the Linux By convention all TopGit branches are usually prefixed with 't/', however
ZFS repo also introduces the convention that the top most development I have chosen not to do this for simplicity. A different convention I have
branch be called 't/LAST". This provides a consistent label to be used adopted is to tag the top most TopGit branch as 'top' for easy reference.
when you need to reference the branch which contains the union of all This provides a consistent label to be used when you need to reference the
topic branches. branch which contains the union of all topic branches.
One thing you may also notice about the 'tg summary' command is it does One thing you may also notice about the 'tg summary' command is it does
not show the branches in dependent order. While this project only expresses not show the branches in dependent order. This is done because TopGit allows
a single dependency per branch TopGit implements dependencies as a DAC just each branch to express multiple dependencies as a DAC. Initially this seemed
like Git. To see the dependencies you will need to use the --graphviz like an added complication which I planned to avoid by just implementing a
option and pipe the result to dot for display. The following command while stack using the graph. However, this ended up being problematic because
long works fairly well for me. Longer term it would be nice to update this with a stack when a change was made to a branch near the base, it was a
option to use a preferred config options stored in the repo if they exist. very expensive operation to merge the change up to the top of the stack.
By defining the dependencies as a graph it is possible to keep the depth
much shallower thus minimizing the merging. It has also proved insightful
as to each patches actual dependencies.
> tg summary --graphviz | dot -Txlib -Nfontsize=8 -Eminlen=0.01 \ To see the dependencies you will need to use the --graphviz option and pipe
-Grankdir=LR -Nheight=0.3 -Nwidth=2 -Nfixedsize=true the result to dot for display. The following command works fairly well for
me. Longer term it would be nice to update this option to use a preferred
config options stored in the repo.
> tg summary --graphviz | dot -Txlib -Nfontsize=8
========================= UPDATING A TOPIC BRANCH ======================== ========================= UPDATING A TOPIC BRANCH ========================