Additional metadata can be stored as comments. i.e. given the right
tools anything that goes from a BK patchset into $SCM can be turned back
into a BK patchset later on. Same holds for the other direction as long
as the comments are preserved.
> And why Arch and not subversion? Subversion has more people working on
> it, Collab has put a pile of money into it, it has the Apache guy working
As far as I could see Tom was talking about bi-directional gateways
between arch, _subversion_, and BK.
> on it, and Arch has one guy with no money and a pile of shell scripts.
That's a pretty harsh statement, especially since critical parts of the
system have already been reimplemented in C or perl. In a way your
comment is almost similar to...
# Writing a new OS only for the 386 in 1991 gets you your second 'F'
# for this term. But if you do real well on the final exam, you can
# still pass the course.
> Come on. There is nothing free in this life, if one guy and some hacking
> could solve this problem, it would have been solved long ago.
Perhaps the time wasn't ripe, ideas and views on SCM systems have
shifted over the years, and yes BK has probably set some new standards
here, but it is always harder to break new ground.
> it's not. Diluting BK down to the level of average SCM is completely
> pointless and a waste of time.
Having an open platform for exchanging patchsets between SCM systems
also allows people to try out different systems. Perhaps they want to
working in parallel with their existing system for a while before
finally moving everything over to the better system.
Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/