[haiku-development] Fwd: Git Vendor Branches [was: Re: haiku: hrev43365 ... ]
- From: Siarzhuk Zharski <zharik@xxxxxx>
- To: "haiku-development@xxxxxxxxxxxxx" <haiku-development@xxxxxxxxxxxxx>
- Date: Wed, 30 Nov 2011 22:57:59 +0100
Hi All,
I have moved this message here because after switching to git using of
"vendor branches"
will be significantly changed, I think. Just to bing info to more wide
audience.
My comments are below of the forwarded message.
-------- Original-Nachricht --------
Betreff: [haiku-commits] Git Vendor Branches [was: Re: haiku: hrev43365
... ]
Datum: Wed, 30 Nov 2011 11:38:55 +0100
Von: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
Antwort an: haiku-commits@xxxxxxxxxxxxx
An: haiku-commits@xxxxxxxxxxxxx
Hi Siarzhuk,
On 2011-11-29 at 23:11:27 [+0100], Siarzhuk Zharski<zharik@xxxxxx> wrote:
On Tue, 29 Nov 2011 15:21:06 -0600, Alexander von Gluck wrote:
>> Author: Alexander von Gluck IV<kallisti5@xxxxxxxxxxx>
>> Date: Tue Nov 29 21:11:34 2011 UTC
>>
>> Add support for newer Realtek RTL8105E ethernet card revision
>>
>> * backport from recent FreeBSD rt driver
2 All: So what is now with the functionality provided earlier by vendor
branch in SVN repo? How should be 3rd party sources tracked now with the
git?
That's a good question, actually: we have a somewhat broken 'vendor' git
repository, that has been created via git-svn from the vendor branches in
our subversion repository. I consider it broken because its structure
doesn't really match expectations: e.g. the 'freebsd' branch only contains
a couple of changesets, missing all of the freebsd-8.x versions (although
the respective tags and changesets are contained in the repository).
I'd started to work on reconstructing the vendor repo from scratch, but
then got stuck in the middle. One of the reasons for that is that there are
at least two different ways of how to do "vendor branches" in git:
1. Simulate subversion and import the trees of vendor releases into a
specific branch of our vendor repository (one branch per vendor product)
and then tag those commits.
2. Use git, git-svn, git-cvs, git-hg and (as a last resort) tree imports to
pull from vendor release branches into our vendor repository, pulling along
the whole history of the vendor branch.
The latter would have the advantage that the actual changesets with their
commit message would be available to the developer trying to update the
vendor code in our repository. In order to avoid pulling in a lot of
changesets from the vendor into our 'haiku' repository, those changesets
should be squashed during the merge (i.e. git merge --squash).
As of now, I tend towards solution 2, but I haven't actually tried it with
the full set of our vendor code.
BTW: In the long run, we should be able to get rid of at least some of the
code we currently have in our vendor repo (and our haiku repo, too) and
move that to HaikuPorts. What can be moved depends on how many changes we
applied to that specific "package", I guess, since HaikuPorts doesn't
really scale well with huge changesets.
Usual workflow of updating compat-drivers on SVN repo was following:
a) The version from some RELASE_X_X_X branch in FreeBSD repo was copied
to vendor/freebsd/current/ branch on our SVN repo in correspondency with
the structure of directories;
b) This version was tagged to corresponding tag in
vendor/freebsd/RELEASE_X_X_X ;
c) The differences between the these release tags were merged to the
trunk, tested and finally committed;
With git (solution 2), we could do this:
[update vendor code]
a) clone the vendor repo
b) enter your local vendor repo, checkout the vendor branch you're
interested in and pull from upstream (or, if the code isn't available via
VCS, do a tree import)
c) tag the new release (if not already tagged in upstream repo)
d) do 'git push --tags' to move changesets& tags into our central vendor
repo
[merge vendor changes with our code]
e) fetch the vendor branch you're interested in from our vendor repo into
your local haiku repo (so that you'll have haiku's master branch and one or
more vendor branches in the same repository)
f) checkout 'master' (or, if you expect a lot of work, a specific branch
for integrating the vendor changes)
g) inspect the vendor changesets (between last and current version) and
apply relevant changesets to our tree ('git merge --squash', or apply the
change manually if the tree structure is too different)
h) build, test and adjust until it works
i) commit the applied changes (which usually will be just a single commit
for vendor code, but additional individual commits for adjustments to our
code would make sense, too)
j) (if you've worked in a specific branch:) merge current branch into master
k) push the changes into our central haiku repository
Because the FreeBSD drivers code were taken with as minimal changes as
possible, most of Haiku-related functionality goes either in glue code
or in compat layer. And it is like a strict requirement to "mark" the
Haiku-related changes in if_*.c files with #ifdef __HAIKU__ sections -
just to let your followers to update the driver with minimal regression,
pain and headache. I personally found very usefull to grab the FreeBSD
driver sources from the CVS repo because CVS expands the "$Id:" keywords
with exact revision of the file and this made the situation clear. In
opposite, files, grabbed from the FreeBSD SVN has no revisions so this
make any update of this source in the future like a Russian Roulette -
"Hm, what I'm going to break today?".
Right, I suppose having the vendor branches history available would make
the task a bit less painful.
To everyone: I'd be just happy to learn that there's an easier way, so
please send your suggestions ;-)
cheers,
Oliver
-------- Ende von Original-Nachricht --------
Yes, our svn vendor freebsd branches were looked for me a bit messed up. For
example the RELEASE_8_2_0 tag
refernced many files from previous releases. And it was always very time
consuming to update, tag and
merge changes into trunk. Especially MII modules, that can be simultaneously
used from the different FreeBSD
release drivers.
--
Kind Regards,
S.Žarski
Other related posts:
- » [haiku-development] Fwd: Git Vendor Branches [was: Re: haiku: hrev43365 ... ] - Siarzhuk Zharski
