Hey Simone, On Sat, Mar 05, 2005 at 21:26:40 +0000, Simone Rota wrote:
On Sat, 5 Mar 2005, Johannes Winkelmann wrote: [...]
If there's any substantial interest, I'd volunteer to initialize the repository for x86, sparc and $TESTARCH (to allow everyone playing with multiple architectures).
I'm interested in working on a uClibc tree; while not strictly a different arch, 20% of ports need some patch against the glibc counterparts, so it could be an interesting testbed. (providing svn compiles and works on uclibc, never tried so far)
In the future I'd like to have some work on a AMD64 port as well. Both of them are very good examples where the subversion setup _might_ save some work.
What about base and opt ports? Will they be included in the SVN repo? I'm still a bit confused about the new port tree layout for CRUX+CLC Right, this is a good remark; in order to be helpful for the SPARC port, base and opt(+contrib) should be there; it would be best if we could sync the clc tree automatically, I'm not sure yet if this can be done easily.
Otherwise, it would just be a test run, in which case I think it would be easiest to use only a few ports.
In general, I think it would be a good idea to make the point of what's going on regarding CRUX 2.1, but this really belongs to another thread. I agree, but in order to discuss this seriously, some experience would be good; if it works out as good as CVS or better, we can certainly consider the switch.
As a (rather interesting) sidenote: I'm not yet sure about the use cases we have, and how well xsvn copes with that; imagine the following: 3-arch setup, x86, x86_64, sparc: 1. a port is added to x86 2. both x86_64 and sparc ports are synced (merged from x86) Now, if the x86 port is updates, sparc and x86_64 can merge nicely, since xsvn set the revision number where it merged from. It's a bit different when the x86_64 maintainer is faster, and the x86 person would like to merge those changes; since we didn't store the branch point from x86 to x86_64, we could only try to be smart (I'm thinking about that right now...). I was wondering whether it would be okay to always require version numbers for cross-platform merges; imagine the above situation, where the x86_64 maintainer was faster with an update, and the x86 maintainer would just like to get those changes, too; in this case, the x86 maintainer would have to find out the revision number of the change (e.g. in the timeline, or via commit notification), and do something like xsvn merge-from sparc64 port -r 100 or if one would want to merge multiple changes, to an xsvn merge-from sparc64 port -r 100,101,102 Not sure if I'm clear here, but implementing a merge tracking which works bidirectional by means of svn properties is certainly not an easy task... and the explicit selection doesn't look all bad to me, since I'd expect that if we would do a simple "merge all that was changed since the last merge", we'd get some unecessary changes. Opinions, questions? Kind regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Bern, Switzerland http://jw.tks6.net