[clc-devel] Request for comments: subversion repository
jw at tks6.net
Mon Mar 7 18:47:50 UTC 2005
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
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
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
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 at tks6.net
Bern, Switzerland http://jw.tks6.net
More information about the crux-devel