Hi, Am 04.07.2010 um 22:05 schrieb Niels Reedijk:
On 4 July 2010 21:18, Andreas Färber <andreas.faerber@xxxxxx> wrote:Where I do see room for improvements however is the SVN vendor branches.Importing flat copies of, e.g., GCC makes us not only loose their CVShistory and diffing the branches slightly complicated / time- consuming, there are no clear patch queues to review. I also fail to see the necessitywhy virtually unmodified versions of dependencies need to live in buildtools/vendor.I have no opinion on putting everything in the vendor dir, but for projects that use svn, would svn:external be of any help?
In theory yes. But only if we upstreamed all Haiku changes, which especially for GCC would incur lag and take away our choice of stable version, so basically no. ;)
Git has a CVS importer but I haven't tried it myself yet. I would imagine that Mercurial might have some extension, too. CVS is always tricky though in that the individually versioned files need to be collected into logical changesets with some heuristic. (For binutils I found that the RedHat guys had done that job so I could just git-clone it.)
[snip] looking at what the upstreams use:Is this for the buildtools?
Yes, projects listed were from buildtools/trunk and buildtools/vendor directories plus MPC as a future candidate. Didn't check buildtools/ legacy subfolder.
For stuff in haiku/src it's easier to continue the Optional Package route I think, as done with sed.
In the list of tools you mention we have all the support for those repositories (git, svn, hg). The svn files could be managed through svn:external (if that is possible with the vendor idea), the others could indeed live on our other repositories. I don't see a reason not to support those as first class citizens.
Slight misformulation on my part above snip'ed, I meant: If a project uses hg we should use hg too for our patching, even if maybe a majority of Haiku users would like to develop Haiku itself with Fossil (to name another VCS). Same for git and bzr projects. It makes the communication easier and gives better choice to try different (esp. more recent) versions - at the cost of initially getting the tool and learning its basic commands. If a project uses SVN, then there's three alternatives to vendor branches: a) svn:external as you suggest, b) a tarball or c) some SVN- compatible DVCS of our choice.
I.e. let's not decide to switch to some DVCS and drag all those buildtools/ files with us into that DVCS, let's split that off from the current, more "/haiku"-centric discussion.
Andreas
