Hi, On Thu, Sep 14, 2006 at 00:50:02 +0400, Anton wrote:
Hi Simone!
I'm very glad that you're seconded svn-contrib idea!
On Wed, Sep 13, 2006 at 09:49:07PM +0200, Simone Rota wrote: [...]
Related topics:
These are somehow related to the introduction of a crux.nu hosted contrib and general repo setup:
- We're currently evaluating other version control apps such as git and mercurial to see if they would fit best our setup, particularly regarding access control and repository separation, also considering that some reorganization of the repo layout could be needed if we decide to include the new contrib. If we agree on a svn replacement, there's the possibility of initially deploy git/hg/other only for the common contrib and migrate core/opt later on when we start working on CRUX 2.3
What problems are you (the developers) seeing with current svn setup?
Except that GIT may *theoretically* solve multiarch issue? Or may not solve. I don't know, yet. It depends on what you consider the multiarch issue. No VCS solves the issues IMHO, since they don't understand the ownership of ports (subdirectories). Especially the distributed VCS' only support tree-wide merges easily (yeah, cherry picking is there, but it's a pain if you don't want to merge a particular change but rather all changes for a particular
The major disadvantage is the weak merge support; this is less important for ports, although it would help branching new versions earlier / less painfully. For our tools though, a distributed VCS would be nice. In addition, at least mercurial does not depend on webdav, which in both svn's and git's case makes us currently depending on apache for the web setup. That said, subversion also has advantages over the two mentioned, so it's a pretty open question. directory), which means that you'd merge all ports if you just want to get the changes in "your" ports. Same for diff, which is again tree wide. In my experience, the change tracking part is a lot more important than the merging itself, since after an initial port to the new architecture, the changes will usually be rather small. At the same time, understanding what the main maintainer changed seems important (even if the change could have been merged automatically). If it's hard to see the changes relevant to you, maintaining an arch branch gets tiresome. Also, a tree-wide merge implies an opt-out situation, i.e. you don't pull in ports because there's a maintainer on your arch but because they exist in $OTHER_ARCH, with the option to drop them in your tree after you merged. BTW, you can use svk against an svn repository, should work equally well as any other distributed vcs.
[1]: Merge'able Pkgfile format is:
version= release= source=( 100%-nonarch-dependable-entries # arch-XYZ can add/remove entries here )
build() { ... ./configure \ --no-arch-dependable-options \ # arch-XYZ add/remove options here \ --disable-nls ... }
Thus, there must be one line per may-be-arch-dependent entry. This is because diff and patch are line-oriented.
The goals for multi-arch support distilled from the previous discussions are: - no changes to the Pkgfile format - no fundamental changes to pkgmk (one thing that most certainly has to be changed to avoid confusions is the name of the binary package, which should contain the build arch) - no changes to ports(8), nor the hierarchy in /usr/ports - no ports should be on $ARCH which aren't maintained and tested - doesn't require a single master tree, i.e. can have "master ports" in more than one arch Of course, for a personal arch port those requirements may be less interesting, it's more for an overall solution with a crux.nu hosted repository. The proposed solution is to use an simple tool to just track ports from master repositories which you sync to your local disk. This has the following properties: - no changes required to any tools or our ports layout - no vcs is enforced: PPC could use cvs, x86 svn, arm git etc, but all can track each others ports. - real maintainer view: - easy to see which of your ports changed - easy to see what changed in your ports - multi-repository, allowing to distribute the maintenance of ports amongst the "serious" architectures - stupid: no automated merges, templates or hidden functionality one has to wrap his (her?) head around, and reducing the sources of errors. It could obviously be extended to support automated merging as well, e.g. using a lightweight local VCS per port, although to me it seemed that compared to the testing of a new version of a port on a particular architecture, merging the Pkgfile changes manually is a minor thing (at least time wise). This approach is loosely based on mppm, the tool Simone used for ucrux, and pretty much the only real experience we have (except mine with some wrapper around svn for sparc, which suffered from the tracking issues mentioned further up). It's certainly an interesting subject, however there's more to it than just the Pkgfile merging if the goal is to create a system which can provide a CRUX port that feels authentical while making it fun to be on the arch maintainer team. HTH, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch