Re: [BK] upgrade will be needed
d.c wrote: El Fri, 18 Feb 2005 13:34:23 -0500 (EST), "Sean" <[EMAIL PROTECTED]> escribió: BK already feeds patches out at the head, surely if it's as powerful as you think, it could feed a free SCM too for your non-bk friends in the community. Who cares, really? 1) Linux was never supposed to have a "head", but -pre/-rc diff patches 2) And more important, *nobody* works against "linus' bk head". Everyone who is implementing something so intrusive that needs to keep track of the "development head" developes again the _true_ "head" of the linux kernel - akpm's tree. If I wanted to develop something which would eventually go into mainline, I certainly would do it against Linus' tree. There are many things going on in -mm which might or might not require significant changes in approach to work. I think -mm is a great place to try the scheduler of the week, but unless some feature requires one of those, it's easier to start from a known base. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Mon, 2005-02-21 at 20:45, [EMAIL PROTECTED] wrote: > CVS was pretty good at keeping files sane, but I'll go for a solution that > completely sidesteps said problem any day. One way to get the benefits of both worlds would be to keep an additional history of changes (in whatever form) that allows to rebuild the ,v files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Mon, 21 Feb 2005, David Roundy wrote: I just scanned the comparison of various source-code management schemes at http://zooko.com/revision_control_quick_ref.html and found myself wishing for a similar review of bk (which was excluded, not being open-source). Would you (or anyone else) be willing to compose a similar evaluation of bk so we amateurs can get a feeling for how these systems differ? Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
[EMAIL PROTECTED] said: > On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote: [...] > > AFIK all other SCM except arch and darcs always modify the repo, I never > > heard complains about it, as long as incremental backups are possible > > and they definitely are possible. > Well, as you seem to have never been bitten by that bug; let me assure you > the problem is very real. Each file (,v file) can live in the repo for > many years and has to servive any spurious writes to be usable. The > curruption of such files (in my experience) only shows itself if you try > to access its history; which may be weeks after the corruption started, > and you can't use a backup for that since you will overwrite new versions > added since. Marking files read-only won't save you from corruption by NFS or the disk or the kernel or... randomly scribbling around. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Mon, Feb 21, 2005 at 04:53:06PM +0100, Andrea Arcangeli wrote: > Hello Miles, > > On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote: > > Yeah, the basic way arch organizes its repository seems _far_ more sane > > than the crazy way CVS (or BK) does, for a variety of reasons[*]. No > > doubt there are certain usage patterns which stress it, but I think it > > makes a lot more sense to use a layer of caching to take care of those, > > rather than screwing up the underlying organization. > > > > [*] (a) Immutability of repository files (_massively_ good idea) > > what is so important about never modifying the repo? Note that only the > global changeset database and a few ,v files will be modified for each > changeset, it's not like we're going to touch all the ,v files for each > checkin. Touching the "modified" ,v files sounds a very minor overhead. > > And you can incremental backup the stuff with recursive diffing the > repo too. > > AFIK all other SCM except arch and darcs always modify the repo, I never > heard complains about it, as long as incremental backups are possible > and they definitely are possible. Well, as you seem to have never been bitten by that bug; let me assure you the problem is very real. Each file (,v file) can live in the repo for many years and has to servive any spurious writes to be usable. The curruption of such files (in my experience) only shows itself if you try to access its history; which may be weeks after the corruption started, and you can't use a backup for that since you will overwrite new versions added since. Think about it this way; nfs servers are known to corrupt things; reboots can corrupt files, different clients will try to write to the file at the same time quite often during the lifetime of the file, cvs clients get killed during writes or network drops the connection during a session. Considering that the ,v files have a lifetime of years, with many modifications during that time, I think its amazing corruption does not happen more often. CVS was pretty good at keeping files sane, but I'll go for a solution that completely sidesteps said problem any day. -- Thomas Zander pgpTm8YJfFbYt.pgp Description: PGP signature
Re: [darcs-users] Re: [BK] upgrade will be needed
On Mon, Feb 21, 2005 at 07:41:54AM -0500, David Roundy wrote: > The catch is that then we'd have to implement a smart server to keep users > from having to download the entire history with each update. That's not a > fundamentally hard issue, but it would definitely degrade darcs' ease of > use, besides putting additional load on the server. So if something like > this were implemented, I think it would definitely have to be as an > optional format. > > Also, we couldn't actually store the data in CVS/SCCS format, since in > darcs a patch to a single file isn't uniquely determined by two states of > that file. But storing separately the patches relevant to different files > would definitely be an optimization worth considering. What about just a cache file that records, for each "file" which patches affect it. Now that I think about it, this is a little tricky, since I'm not sure what that file would be called. It would be easy to do for filenames in the current version. Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
Hello Miles, On Mon, Feb 21, 2005 at 02:39:05PM +0900, Miles Bader wrote: > Yeah, the basic way arch organizes its repository seems _far_ more sane > than the crazy way CVS (or BK) does, for a variety of reasons[*]. No > doubt there are certain usage patterns which stress it, but I think it > makes a lot more sense to use a layer of caching to take care of those, > rather than screwing up the underlying organization. > > [*] (a) Immutability of repository files (_massively_ good idea) what is so important about never modifying the repo? Note that only the global changeset database and a few ,v files will be modified for each changeset, it's not like we're going to touch all the ,v files for each checkin. Touching the "modified" ,v files sounds a very minor overhead. And you can incremental backup the stuff with recursive diffing the repo too. AFIK all other SCM except arch and darcs always modify the repo, I never heard complains about it, as long as incremental backups are possible and they definitely are possible. > (b) Deals with tree-changes "naturally" (CVS-style ,v files are a > complete mess for anything except file-content changes) Certainly it's more complicated but I believe the end result will be a better on-disk format. Don't get me wrong, current disk format is great already for small projects, it's the simplest approach and it's very reliable, but I don't think the current on-disk it scales up to the l-k with reasonable performance. > (c) Directly corresponds to traditional diff 'n' patch, easy to > think about, no surprises Nobody is supposed to touch the repo with an editor anyway, all it matters is how fast the command works. And you'll be able to ask to the SCM "show me all changesets touching this file, or even ""this range" of the file"", in the last 2 years" and get an answer in dozen seconds like with cvsps today. even cvsps creates an huge cache, but it doesn't need to unpack >2 tar.gz tarballs to create its cache. Feel free to prove me wrong and covert current kernel CVS to arch and see how big it grows unpacked ;). Anyway this is quickly going offtopic with l-k, so we should take it to darcs and arch lists. Thanks! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Dmitry Torokhov wrote: It's not too bad as you just hardlink most of the trees to their parent. Yes, and disk space is cheap. I think there is a setting to have them checked out for editing automatically. Yes there is, plus most decent editors are SCCS-aware and will prompt for a checkout when you try edit a locked file anyway (emacs certainly does, without any add-on modules). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Saturday 19 February 2005 12:53 pm, Andrea Arcangeli wrote: > Wouldn't using the CVS format help an order of magnitude here? With > CVS/SCCS format you can extract all the patchsets that affected a single > file in a extremely efficient manner, memory utilization will be > extremely low too (like in cvsps indeed). You'll only have to lookup the > "global changeset file", and then open the few ,v files that are > affected and extract their patchsets. cvsps does this optimally > already. The only difference is that what cvsps is a "readonly" cache, > while with a real SCM it would be a global file that control all the > changesets in an atomic way. But then that makes darcs do stuff the cvs way, and would make darcs exactly the opposite of how us darcs users want it, imho. If you're worried about darcs needing to open a billion files, nothing stops people from, say, hacking darcs to use a SQL database to store patches in (they just have to code it, and I think I saw a SQL module for haskell around somewhere...) May be I just don't understand the argument of why the CVS file format is anything short of insane, backwards, and outdated. We want each chunk of information to be both independent and have a clear history (ie, what patches does this patch rely on). CVS does not provide this, it is not fine grained enough for what darcs needs. (David Roundy and Co can fill in the technical details of this, I'm not a versioning system expert) In short, we need to move as far away from the CVS way of doing things, because ultimately its the wrong way. This is why I am somewhat dismayed when I hear of projects who move to SVN from CVS... SVN is just CVS with a few flaws fixed, and a few things like atomic commits added. It isn't the next step: it is just a small stepping stone between CVS and the next step. -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpB5eGVGeUue.pgp Description: PGP signature
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 06:53:48PM +0100, Andrea Arcangeli wrote: > On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote: > > The linux-2.5 tree right now (I'm re-doing the conversion, and am up to > > October of last year, so far) is at 141M, if you don't count the pristine > > cache or working directory. That's already compressed, so you don't get > > any extra bonuses. Darcs stores with each changeset both the old and new > > versions of each hunk, which gives you some redundancy, and probably > > accounts for the factor of two greater size than CVS. This gives a bit of > > redundancy, which can be helpful in cases of repository corruption. > > Double size of the compressed backup is about the same as SVM with fsfs > (not tested on l-k tree but in something much smaller). Why not to > simply checksum instead of having data redundancy? Knowing when > something is corrupted is a great feature, but doing raid1 without the > user asking for it, is a worthless overhead. There are internal issues that would cause trouble here--darcs assumes that if it knows a given patch, it also knows the patch's inverse. > > I hope to someday (when more pressing issues are dealt with) add a per-file > > cache indicating which patches affect which files, which should largely > > address this problem, although it won't help at all with files that are > > touched by most of the changesets, and won't be optimimal in any case. :( > > Wouldn't using the CVS format help an order of magnitude here? With > CVS/SCCS format you can extract all the patchsets that affected a single > file in a extremely efficient manner, memory utilization will be > extremely low too (like in cvsps indeed). You'll only have to lookup the > "global changeset file", and then open the few ,v files that are > affected and extract their patchsets. cvsps does this optimally > already. The only difference is that what cvsps is a "readonly" cache, > while with a real SCM it would be a global file that control all the > changesets in an atomic way. The catch is that then we'd have to implement a smart server to keep users from having to download the entire history with each update. That's not a fundamentally hard issue, but it would definitely degrade darcs' ease of use, besides putting additional load on the server. So if something like this were implemented, I think it would definitely have to be as an optional format. Also, we couldn't actually store the data in CVS/SCCS format, since in darcs a patch to a single file isn't uniquely determined by two states of that file. But storing separately the patches relevant to different files would definitely be an optimization worth considering. -- David Roundy http://www.darcs.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Monday 21 February 2005 00:43, Miles Bader wrote:
> "Theodore Ts'o" <[EMAIL PROTECTED]> writes:
> > The "cost" of using BK seems to be primarily more theoretical, and
> > ideological, than real.
>
> I've never used BK (not allowed to), but some things I've read about it
> sound quite annoying. For instance:
>
> * Every source tree contains your entire repository => massive disk usage
It's not too bad as you just hardlink most of the trees to their parent.
> * Must "unlock" files before working on them ("bk edit"); I recall
>doing this with RCS, and it was, well, a real pain.
I think there is a setting to have them checked out for editing automatically.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
"Theodore Ts'o" <[EMAIL PROTECTED]> writes:
> The "cost" of using BK seems to be primarily more theoretical, and
> ideological, than real.
I've never used BK (not allowed to), but some things I've read about it
sound quite annoying. For instance:
* Every source tree contains your entire repository => massive disk usage
* Must "unlock" files before working on them ("bk edit"); I recall
doing this with RCS, and it was, well, a real pain.
-Miles
--
"Whatever you do will be insignificant, but it is very important that
you do it." Mahatma Ghandi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
Dustin Sallings writes: > but the nicest thing about arch is that a given commit is immutable. > There are no tools to modify it. This is also why the crypto > signature stuff was so easy to fit in. > > RCS and SCCS storage throws away most of those features. Yeah, the basic way arch organizes its repository seems _far_ more sane than the crazy way CVS (or BK) does, for a variety of reasons[*]. No doubt there are certain usage patterns which stress it, but I think it makes a lot more sense to use a layer of caching to take care of those, rather than screwing up the underlying organization. [*] (a) Immutability of repository files (_massively_ good idea) (b) Deals with tree-changes "naturally" (CVS-style ,v files are a complete mess for anything except file-content changes) (c) Directly corresponds to traditional diff 'n' patch, easy to think about, no surprises -Miles -- Saa, shall we dance? (from a dance-class advertisement) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
Hi, David Roundy, creator of darcs, wrote: > On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote: > > I read in the webpage of the darcs kernel repository that they had > > to add RAM serveral times to avoid running out of memory. They > > needed more than 1G IIRC, and that was enough for me to lose > > interest into it. You're right I blamed the functional approach and > > so I felt it was going to be a mess to fix the ram utilization, but > > as someone else pointed out, perhaps it's darcs to blame and not > > haskell. I don't know. > > Darcs' RAM use has indeed already improved somewhat... I'm not exactly > sure how much. I'm not quite sure how to measure peak virtual memory > usage, and most of the time darcs' memory use while doing the linux > kernel conversion is under a couple of hundred megabytes. Wouldn't calling sbrk(0) help? I don't know if the Haskell run-time ever shrinks the data segment, if not, it could just be called at the end. Or a `strace -e trace=brk darcs ...' might do. But I guess darcs has other VM usage that doesn't show in this figure? Does /proc/$$/maps if running under Linux help? A consistent way to measure would be handy for observing changes over time. Cheers, Ralph. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 12:15:02PM -0500, David Roundy wrote: > The linux-2.5 tree right now (I'm re-doing the conversion, and am up to > October of last year, so far) is at 141M, if you don't count the pristine > cache or working directory. That's already compressed, so you don't get > any extra bonuses. Darcs stores with each changeset both the old and new > versions of each hunk, which gives you some redundancy, and probably > accounts for the factor of two greater size than CVS. This gives a bit of > redundancy, which can be helpful in cases of repository corruption. Double size of the compressed backup is about the same as SVM with fsfs (not tested on l-k tree but in something much smaller). Why not to simply checksum instead of having data redundancy? Knowing when something is corrupted is a great feature, but doing raid1 without the user asking for it, is a worthless overhead. The same is true for arch of course, last time I checked they were using the default -U 3 format instead of -U 0. > I presume you're referring to a local checkout? That is already done using > hard links by darcs--only of course the working directory has to actually > be copied over, since there are editors out there that aren't friendly to > hard-linked files. arch allows to hardlink the copy too (optionally) and it's up to you to use the right switch in the editor (Davide had a LD_PRELOAD to do a copy-on-write since the kernel doesn't provide the feature). > And here's where darcs really falls down. To track the history of a single > file it has to read the contents of every changeset since the creation of > that file, which will take forever (well, not quite... but close). Indeed, and as I mentioned this is the *major* feature as far as I'm concerned (and frankly the only one I really care about and that helps a lot to track changes in the tree and understand why the code evolved). Note that cvsps works great for this, it's very efficient as well (not remotely comparable to arch at least, even if arch provided a tool equivalent to cvsps), the only problem is that CVS is out of sync... > I hope to someday (when more pressing issues are dealt with) add a per-file > cache indicating which patches affect which files, which should largely > address this problem, although it won't help at all with files that are > touched by most of the changesets, and won't be optimimal in any case. :( Wouldn't using the CVS format help an order of magnitude here? With CVS/SCCS format you can extract all the patchsets that affected a single file in a extremely efficient manner, memory utilization will be extremely low too (like in cvsps indeed). You'll only have to lookup the "global changeset file", and then open the few ,v files that are affected and extract their patchsets. cvsps does this optimally already. The only difference is that what cvsps is a "readonly" cache, while with a real SCM it would be a global file that control all the changesets in an atomic way. Infact *that* global file could be a bsddb too, I don't care about how the changset file is being encoded, all I care is that the data is a ,v file or SCCS file so cvsps won't have to read >2 files every time I ask that question, which is currently unavoidable with both darcs and arch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 05:42:13PM +0100, Andrea Arcangeli wrote: > But anyway the only thing I care about is that you import all dozen > thousands changesets of the 2.5 kernel into it, and you show it's > manageable with <1G of ram and that the backup size is not very far from > the 75M of CVS. The linux-2.5 tree right now (I'm re-doing the conversion, and am up to October of last year, so far) is at 141M, if you don't count the pristine cache or working directory. That's already compressed, so you don't get any extra bonuses. Darcs stores with each changeset both the old and new versions of each hunk, which gives you some redundancy, and probably accounts for the factor of two greater size than CVS. This gives a bit of redundancy, which can be helpful in cases of repository corruption. > I read in the webpage of the darcs kernel repository that they had to > add RAM serveral times to avoid running out of memory. They needed more > than 1G IIRC, and that was enough for me to lose interest into it. > You're right I blamed the functional approach and so I felt it was going > to be a mess to fix the ram utilization, but as someone else pointed > out, perhaps it's darcs to blame and not haskell. I don't know. Darcs' RAM use has indeed already improved somewhat... I'm not exactly sure how much. I'm not quite sure how to measure peak virtual memory usage, and most of the time darcs' memory use while doing the linux kernel conversion is under a couple of hundred megabytes. There are indeed trickinesses involved in making sure garbage gets collected in a timely manner when coding in a lazy language like haskell. > On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote: > > Thats all up to how the versioning system is written. Darcs developers > > are working in a checkpoint system to allow you to just grab the newest > > stuff, Correction: we already have a checkpoint system. The work in progress is making commands that examine the history fail gracefully when that history isn't present. > This is already available with arch. In fact I suggested myself how to > improve it with hardlinks so that a checkout will take a few seconds no > matter the size of the tree. I presume you're referring to a local checkout? That is already done using hard links by darcs--only of course the working directory has to actually be copied over, since there are editors out there that aren't friendly to hard-linked files. > > and automatically grab anything else you need, instead of just grabbing > > everything. In the case of the darcs linux repo, no one wants to > > download 600 megs or so of changes. > > If you use arch/darcs as a patch-download tool, then that's fine ... > The major reason a versioning system is useful to me is to track all > changesets that touched a single file since the start of 2.5 to the > head. So I can't get away by downloading the last dozen patches and > caching the previous tree (which is perfectly doable with arch for ages > and with hardlinks as well). And here's where darcs really falls down. To track the history of a single file it has to read the contents of every changeset since the creation of that file, which will take forever (well, not quite... but close). I hope to someday (when more pressing issues are dealt with) add a per-file cache indicating which patches affect which files, which should largely address this problem, although it won't help at all with files that are touched by most of the changesets, and won't be optimimal in any case. :( -- David Roundy http://www.darcs.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, Feb 19, 2005 at 04:10:18AM -0500, Patrick McFarland wrote: > In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By > using it's super magical method, it represents how code is written and how it > changes (patch theory at its best). You can clearly see the direction code is > going, where it came from, and how it relates to other patches. I don't know anything about darcs, I was only talking about arch. I failed to compile darcs after trying for a while, so I give it up, I'll try again eventually. But anyway the only thing I care about is that you import all dozen thousands changesets of the 2.5 kernel into it, and you show it's manageable with <1G of ram and that the backup size is not very far from the 75M of CVS. I read in the webpage of the darcs kernel repository that they had to add RAM serveral times to avoid running out of memory. They needed more than 1G IIRC, and that was enough for me to lose interest into it. You're right I blamed the functional approach and so I felt it was going to be a mess to fix the ram utilization, but as someone else pointed out, perhaps it's darcs to blame and not haskell. I don't know. To me backup size matters too and for example I'm quite happy the fsfs backend of SVN generates very small backups compared to bsddb. > Sure, you can do this with RCS/SCCS style versioning, but whats the point? It > is inefficient, and backwards. It is saved in a compact format, and I don't think it'll run slower since if it's in cache it'll be fast and if it's I/O dominaed the more compact it is, the faster it will be, having a compact size both for the repository and for the backup, is more important to me. In theory one could write a backup tool that extracts the thing and rewrite a special backup-backend that is as space efficient as CVS and that can compress as well as CVS, but this won't help the working copy. > Thats all up to how the versioning system is written. Darcs developers are > working in a checkpoint system to allow you to just grab the newest stuff, This is already available with arch. Infact I suggested myself how to improve it with hardlinks so that a checkout will take a few seconds no matter the size of the tree. > and automatically grab anything else you need, instead of just grabbing > everything. In the case of the darcs linux repo, no one wants to download 600 > megs or so of changes. If you use arch/darcs as a patch-download tool, then that's fine as you say and you can already do that with arch (that in this part seems already a lot more advanced and it's written in C btw). Most people just checking out the kernel with arch (or darcs) would never need to download 600Megs of changes, but I need to download them all. The major reason a versioning system is useful to me is to track all changesets that touched a single file since the start of 2.5 to the head. So I can't get away by downloading the last dozen patches and caching the previous tree (which is perfectly doable with arch for ages and with hardlinks as well). > It may not even be space efficient. Code ultimately is just code, and changes > ultimately are changes. RCS isn't magical, and its far from it. Infact, the The way RCS stores the stuff compresses great. In that is "magical". I guess SCCS is the same. fsfs isn't bad either though, and infact I'd never use bsddb and I'd only use fsfs with SVN. > The darcs repo which has the entire history since at least the start of 2.4 > (iirc anyways) to *now* is around 600 to 700. > My suggestion is to convert _all_ dozen thousand changesets to darcs, and > then > compare the size with CVS. And no, darcs doesn't eat that much memory for the What is the above 600/700 number then? I thought that was the conversion of all dozen thousand changesets of linux-2.5 CVS to darcs. > amount of work its doing. (And yes, they are working on that). I'll stay tuned. To me the only argument for not using a "magic" format like CVS or SCCS that is space efficient and compresses efficiently, is if you claim it's going to be a lot slower at checkouts (but infact applying some dozen thousand patchsets to run a checkout is going to be slower than CVS/SCCS). I know it's so much simpler to keep each patchset in a different file like arch is already doing, but that's not the best on-disk format IMHO. Note that some year ago I had the opposite idea, i.e. at some point I got convinced it was so much better to keep each patch separated from each other like you're advocating above, until I figured out how big the thing grows and how little space efficient it is, and how much I/O it forces me to do, how much disk it wastes in the backup and how slow it is as well to checkout dozen thousand patchsets. For smaller projects without dozen thousand changesets, the patch per file looks fine instead. For big projects IMHO being space efficient is much more important. - To unsubscribe from this list: send the line "unsubscribe linux-k
Re: [darcs-users] Re: [BK] upgrade will be needed
On Sat, February 19, 2005 4:10 am, Patrick McFarland said: > On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote: >> On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote: >> > RCS/SCCS format doesn't make much sence for a changeset oriented SCM. >> >> The advantage it will provide is that it'll be compact and a backup will >> compress at best too. Small compressed tarballs compress very badly >> instead, it wouldn't be even comparable. Once the thing is very compact >> it has a better chance to fit in cache, and if it fits in cache >> extracting diffs from each file will be very fast. Once it'll be compact >> the cost of a changeset will be diminished allowing it to scale better >> too. > > In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. > By > using it's super magical method, it represents how code is written and how > it > changes (patch theory at its best). You can clearly see the direction code > is > going, where it came from, and how it relates to other patches. > > Sure, you can do this with RCS/SCCS style versioning, but whats the point? > It > is inefficient, and backwards. > >> Now it's true new disks are bigger, but they're not much faster, so if >> the size of the repository is much larger, it'll be much slower to >> checkout if it doesn't fit in cache. And if it's smaller it has better >> chances of fitting in cache too. > > Thats all up to how the versioning system is written. Darcs developers are > working in a checkpoint system to allow you to just grab the newest stuff, > and automatically grab anything else you need, instead of just grabbing > everything. In the case of the darcs linux repo, no one wants to download > 600 > megs or so of changes. > >> The thing is, RCS seems a space efficient format for storing patches, >> and it's efficient at extracting them too (plus it's textual so it's not >> going to get lost info even if something goes wrong). > > It may not even be space efficient. Code ultimately is just code, and > changes > ultimately are changes. RCS isn't magical, and its far from it. Infact, > the > format darcs uses probably stores more code in less space, but don't quote > me > on that. > >> The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed. > > The darcs repo which has the entire history since at least the start of > 2.4 > (iirc anyways) to *now* is around 600 to 700. > >> My suggestion is to convert _all_ dozen thousand changesets to arch or >> SVN and then compare the size with CVS (also the compressed size is >> interesting for backups IMHO). Unfortunately I know nothing about darcs >> yet (except it eats quite some memory ;) > > My suggestion is to convert _all_ dozen thousand changesets to darcs, and > then > compare the size with CVS. And no, darcs doesn't eat that much memory for > the > amount of work its doing. (And yes, they are working on that). > > The only thing you haven't brought up is the whole "omgwtfbbq! BK sucks, > lets > switch to SVN or Arch!" thing everyone else in the known universe is > doing. > BK isn't clearly inferior or superior to SVN or Arch or Darcs (and the > same > goes for SVN vs Arch vs Darcs). > > (Start Generic BK Thread On LKML Rant) > > Dear Everyone, > > I think if Linus is happy with BK, he should stick with it. His opinion > ultimately trumps all of ours because he does all the hard maintainership > work, and we don't. The only guy that gets to bitch about how much a > versioning system sucks is the maintainer of a project (unless its CVS, > then > all bets are off). > > Linus has so far indicated that he likes BK, so the kernel hacking > community > will be stuck using that for awhile. However, that doesn't stop the > license > kiddies from coming out of the woodwork and mindlessly quoting the bad > parts > of the BK license (which, yes, its non-free, but at this point, who gives > a > shit). > > IMO, yes, a non-free versioning system for the crown jewel of the FLOSS > community is a little... odd, but it was LInus's choice, and we now have > to > respect it/deal with it. > > Now, I did say above (in this thread) that darcs would be really awesome > for > kernel hacking, especially since it's inherent support for multiple > branches[1] and the ability to send changes from each other around easily > would come in handy; however, darcs was not mature at the time of Linus's > decision (and many say it is still not mature enough), so if Linus had > actually chosen darcs, I (and other people here) would be now flaming him > for > choosing a versioning system that wasn't mature. > > Similarly, if he had chosen arch, everyone would have flamed him for > choosing > a hard to use tool. With svn, he would have met flamage by the hands of it > being too much like cvs and not supporting arch/darcs style branch > syncing. > And if he stayed with cvs, he would have been roasted over an open fire > for > sticking with an out of date, useless, insane tool. > > And if he chose anythin
Re: [darcs-users] Re: [BK] upgrade will be needed
On Friday 18 February 2005 07:50 am, Andrea Arcangeli wrote: > On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote: > > RCS/SCCS format doesn't make much sence for a changeset oriented SCM. > > The advantage it will provide is that it'll be compact and a backup will > compress at best too. Small compressed tarballs compress very badly > instead, it wouldn't be even comparable. Once the thing is very compact > it has a better chance to fit in cache, and if it fits in cache > extracting diffs from each file will be very fast. Once it'll be compact > the cost of a changeset will be diminished allowing it to scale better > too. In the case of darcs, RCS/SCCS works exactly opposite of how darcs does. By using it's super magical method, it represents how code is written and how it changes (patch theory at its best). You can clearly see the direction code is going, where it came from, and how it relates to other patches. Sure, you can do this with RCS/SCCS style versioning, but whats the point? It is inefficient, and backwards. > Now it's true new disks are bigger, but they're not much faster, so if > the size of the repository is much larger, it'll be much slower to > checkout if it doesn't fit in cache. And if it's smaller it has better > chances of fitting in cache too. Thats all up to how the versioning system is written. Darcs developers are working in a checkpoint system to allow you to just grab the newest stuff, and automatically grab anything else you need, instead of just grabbing everything. In the case of the darcs linux repo, no one wants to download 600 megs or so of changes. > The thing is, RCS seems a space efficient format for storing patches, > and it's efficient at extracting them too (plus it's textual so it's not > going to get lost info even if something goes wrong). It may not even be space efficient. Code ultimately is just code, and changes ultimately are changes. RCS isn't magical, and its far from it. Infact, the format darcs uses probably stores more code in less space, but don't quote me on that. > The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed. The darcs repo which has the entire history since at least the start of 2.4 (iirc anyways) to *now* is around 600 to 700. > My suggestion is to convert _all_ dozen thousand changesets to arch or > SVN and then compare the size with CVS (also the compressed size is > interesting for backups IMHO). Unfortunately I know nothing about darcs > yet (except it eats quite some memory ;) My suggestion is to convert _all_ dozen thousand changesets to darcs, and then compare the size with CVS. And no, darcs doesn't eat that much memory for the amount of work its doing. (And yes, they are working on that). The only thing you haven't brought up is the whole "omgwtfbbq! BK sucks, lets switch to SVN or Arch!" thing everyone else in the known universe is doing. BK isn't clearly inferior or superior to SVN or Arch or Darcs (and the same goes for SVN vs Arch vs Darcs). (Start Generic BK Thread On LKML Rant) Dear Everyone, I think if Linus is happy with BK, he should stick with it. His opinion ultimately trumps all of ours because he does all the hard maintainership work, and we don't. The only guy that gets to bitch about how much a versioning system sucks is the maintainer of a project (unless its CVS, then all bets are off). Linus has so far indicated that he likes BK, so the kernel hacking community will be stuck using that for awhile. However, that doesn't stop the license kiddies from coming out of the woodwork and mindlessly quoting the bad parts of the BK license (which, yes, its non-free, but at this point, who gives a shit). IMO, yes, a non-free versioning system for the crown jewel of the FLOSS community is a little... odd, but it was LInus's choice, and we now have to respect it/deal with it. Now, I did say above (in this thread) that darcs would be really awesome for kernel hacking, especially since it's inherent support for multiple branches[1] and the ability to send changes from each other around easily would come in handy; however, darcs was not mature at the time of Linus's decision (and many say it is still not mature enough), so if Linus had actually chosen darcs, I (and other people here) would be now flaming him for choosing a versioning system that wasn't mature. Similarly, if he had chosen arch, everyone would have flamed him for choosing a hard to use tool. With svn, he would have met flamage by the hands of it being too much like cvs and not supporting arch/darcs style branch syncing. And if he stayed with cvs, he would have been roasted over an open fire for sticking with an out of date, useless, insane tool. And if he chose anything else that I didn't previously mention, everyone would have donned flame retardant suits and went into the fray over the fact that no one has heard of that versioning system. No matter what choice Linus would have
Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005, Dmitry Torokhov wrote: > On Fri, 18 Feb 2005 23:18:19 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 18, 2005 at 09:34:47PM +, Anton Altaparmakov wrote: > > > On Fri, 18 Feb 2005, David S. Miller wrote: > > > > On Fri, 18 Feb 2005 21:45:55 +0100 > > > > "d.c" <[EMAIL PROTECTED]> wrote: > > > > > > > > > 2) And more important, *nobody* works against "linus' bk head". > > > > > > > > I do, %100 exclusively, for all the networking and sparc > > > > development. > > > > > > > > I never work against the -mm tree. > > > > > > Dito. All my kernel development happens against Linus' bk head and I > > > almost never work against -mm tree. > > > > Same here, I work on Linus's bk head and all the changes go to -mm for > > testing first, then to Linus for inclusion. > > I guess there is a perception that developers/maintainers are working > against -mm because all maintainers trees are automatically pulled by > Andrew. And when someone doing stuff on somewhat regular basis he/she > tends to do it against maintainer's tree thus making patches suitable > for -mm as well. Ah yes, that is possible. However at least for me I work against Linus' BK head, but my developmental NTFS tree is pulled by Andrew for -mm. When I consider a release ready I request inclusion into Linus' tree. For non-ntfs stuff I generally send to Andrew for -mm (like the loop driver fallback to file write patch I sent him a few days ago) and he can merge it into mainline later. I imagine it is simillar for most maintainers trees. Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
"Sean" <[EMAIL PROTECTED]> said: [...] > Yeah, I didn't mean to suggest that it be opened up to the public :o) > Just that the flow of information wouldn't all have to originate in bk to > make it into head (ie. bk could pull changes from head too). No problem. bk can happily import patches, which you can certainly get out of any other SCM. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005 23:18:19 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote: > On Fri, Feb 18, 2005 at 09:34:47PM +, Anton Altaparmakov wrote: > > On Fri, 18 Feb 2005, David S. Miller wrote: > > > On Fri, 18 Feb 2005 21:45:55 +0100 > > > "d.c" <[EMAIL PROTECTED]> wrote: > > > > > > > 2) And more important, *nobody* works against "linus' bk head". > > > > > > I do, %100 exclusively, for all the networking and sparc > > > development. > > > > > > I never work against the -mm tree. > > > > Dito. All my kernel development happens against Linus' bk head and I > > almost never work against -mm tree. > > Same here, I work on Linus's bk head and all the changes go to -mm for > testing first, then to Linus for inclusion. > I guess there is a perception that developers/maintainers are working against -mm because all maintainers trees are automatically pulled by Andrew. And when someone doing stuff on somewhat regular basis he/she tends to do it against maintainer's tree thus making patches suitable for -mm as well. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, Feb 18, 2005 at 09:34:47PM +, Anton Altaparmakov wrote: > On Fri, 18 Feb 2005, David S. Miller wrote: > > On Fri, 18 Feb 2005 21:45:55 +0100 > > "d.c" <[EMAIL PROTECTED]> wrote: > > > > > 2) And more important, *nobody* works against "linus' bk head". > > > > I do, %100 exclusively, for all the networking and sparc > > development. > > > > I never work against the -mm tree. > > Dito. All my kernel development happens against Linus' bk head and I > almost never work against -mm tree. Same here, I work on Linus's bk head and all the changes go to -mm for testing first, then to Linus for inclusion. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005, David S. Miller wrote: > On Fri, 18 Feb 2005 21:45:55 +0100 > "d.c" <[EMAIL PROTECTED]> wrote: > > > 2) And more important, *nobody* works against "linus' bk head". > > I do, %100 exclusively, for all the networking and sparc > development. > > I never work against the -mm tree. Dito. All my kernel development happens against Linus' bk head and I almost never work against -mm tree. Best regards, Anton -- Anton Altaparmakov (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005 21:45:55 +0100 "d.c" <[EMAIL PROTECTED]> wrote: > 2) And more important, *nobody* works against "linus' bk head". I do, %100 exclusively, for all the networking and sparc development. I never work against the -mm tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
El Fri, 18 Feb 2005 13:34:23 -0500 (EST), "Sean" <[EMAIL PROTECTED]> escribió: > BK already feeds patches out at the head, surely if it's as powerful as > you think, it could feed a free SCM too for your non-bk friends in the > community. Who cares, really? 1) Linux was never supposed to have a "head", but -pre/-rc diff patches 2) And more important, *nobody* works against "linus' bk head". Everyone who is implementing something so intrusive that needs to keep track of the "development head" developes again the _true_ "head" of the linux kernel - akpm's tree. In fact is surprising that so many people are bitching about BK and nobody has complained that the -mm tree is not available through a SCM system (be it free or not), which should be a issue _much_ bigger than any problem you've with BK. I just don't get it, in my opinion people who whines about BK is people who just don't like BK and can't accept the fact that BK is really helping to linux development. When RMS started GNU he had to use non-free tools and systems to work on it because everythin else sucked or it would have been more difficult, I don't think BK is much different in this regard. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, February 18, 2005 2:49 pm, Dmitry Torokhov said: > You from cvs you can import into other SCM of your choise. This isn't true unfortunately, a lot of information is lost in cvs. file deletes, renames etc.. Plus, the implementation from Bitkeeper is lacking, (eg. combining many changes into one). > > Heh, you don't get to update the master repository even if you are > using BK. And you are free to update your local tree with > CVS/SVN/whatever. So I am not sure why you trying this argument. Yeah, I didn't mean to suggest that it be opened up to the public :o) Just that the flow of information wouldn't all have to originate in bk to make it into head (ie. bk could pull changes from head too). Cheers, Sean. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005 14:31:20 -0500 (EST), Sean <[EMAIL PROTECTED]> wrote: > On Fri, February 18, 2005 2:26 pm, Dmitry Torokhov said: > > > What is bk2cvs gateway that is maintained by Larry then? Just call it > > your "head" that Linus feeds from his BK repository and you are all > > set. > > > > I can see that Roman and Stellian want something different, but we > > alerady have what you have just described. > > > > Bitkeeper isn't motivated to raise the bar in terms of implementation, nor > is cvs the best choice in terms of which free tool to use. You from cvs you can import into other SCM of your choise. > Once a free > SCM is actually used at the head, there are opportunities to implement > updating too, not just pulling. Heh, you don't get to update the master repository even if you are using BK. And you are free to update your local tree with CVS/SVN/whatever. So I am not sure why you trying this argument. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
> "Sean" == Sean <[EMAIL PROTECTED]> writes: Sean> Bitkeeper isn't motivated to raise the bar in terms of Sean> implementation, nor is cvs the best choice in terms of which Sean> free tool to use. Once a free SCM is actually used at the head, Sean> there are opportunities to implement updating too, not just Sean> pulling. Great, come on back when you've implemented this new tool and show everyone how great it is. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, February 18, 2005 2:26 pm, Dmitry Torokhov said: > What is bk2cvs gateway that is maintained by Larry then? Just call it > your "head" that Linus feeds from his BK repository and you are all > set. > > I can see that Roman and Stellian want something different, but we > alerady have what you have just described. > Bitkeeper isn't motivated to raise the bar in terms of implementation, nor is cvs the best choice in terms of which free tool to use. Once a free SCM is actually used at the head, there are opportunities to implement updating too, not just pulling. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005 13:34:23 -0500 (EST), Sean <[EMAIL PROTECTED]> wrote: > On Fri, February 18, 2005 11:27 am, Theodore Ts'o said: > > > If you truly believe that BK would be able to add the value that it > > does to the kernel development process by using some other SCM as the > > master SCM, with BK being "underneath", as you proposed earlier, then > > you do not understand why BK is fundamentally better than the current > > open source SCM systems that are out there. > > BK already feeds patches out at the head, surely if it's as powerful as > you think, it could feed a free SCM too for your non-bk friends in the > community. What is bk2cvs gateway that is maintained by Larry then? Just call it your "head" that Linus feeds from his BK repository and you are all set. I can see that Roman and Stellian want something different, but we alerady have what you have just described. -- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, February 18, 2005 11:27 am, Theodore Ts'o said: > If you truly believe that BK would be able to add the value that it > does to the kernel development process by using some other SCM as the > master SCM, with BK being "underneath", as you proposed earlier, then > you do not understand why BK is fundamentally better than the current > open source SCM systems that are out there. BK already feeds patches out at the head, surely if it's as powerful as you think, it could feed a free SCM too for your non-bk friends in the community. > And people *can* use the tools of their choice today. They can use > CVS, and diff+patch, and suffer with all of the limitations that those > tools have today. And for people who are doing stuff around the > periphery, quilt is often really the best tool for them. The situation could be improved for these other tools if there wasn't so much BK zealotry from those that use it. > If it's about the whole ***kernel*** development community, then it's > pretty clear that the current system works quite well. All of the > complaints have been coming primarily from SCM hackers, it seems, and > not people who truly need the power of more powerful than downloading > the bk snapshots, using the CVS export tree, and in the case where > they need to look at the changes in a single changeset bkbits.net. There's no technical reason for this limitation. > The "cost" of using BK seems to be primarily more theoretical, and > ideological, than real. It's always seems to be about someone > kvetching that they want to use SVN and get finely grained changsets > through SVN, and they can't. But how often does that happen, and > what's so painful of getting the finely grained changeset through > bkbits.net? Not very. So at the end of the day, it finally boils > down to being all about ideology, doesn't it? No. It's just that the cost isn't being paid by you, so you don't care. Cheers, Sean. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Feb 18, 2005, at 1:09, Andrea Arcangeli wrote: darcs scares me a bit because it's in haskell, I don't believe very much in functional languages for compute intensive stuff, ram utilization It doesn't sound like you've programmed in functional languages all that much. While I don't have any practical experience in Haskell, I can say for sure that my functional code in ocaml blows my C code away in maintainability and performance. Now, if I could only get it to dump core... Haskell was a draw for me. It's very rare to find someone who actually knows C and can write bulletproof code in it. On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote: RCS/SCCS format doesn't make much sence for a changeset oriented SCM. The advantage it will provide is that it'll be compact and a backup will compress at best too. Small compressed tarballs compress very badly instead, it wouldn't be even comparable. Once the thing is very compact it has a better chance to fit in cache, and if it fits in cache extracting diffs from each file will be very fast. Once it'll be compact the cost of a changeset will be diminished allowing it to scale better too. Then what gets transferred over the wire? The full modified ,v file? Do you need a smart server to create deltas to be applied to your ,v files? What do you do when someone goes in with an rcs command to destroy part of the history (since the storage is now mutable). I use both darcs and arch regularly. darcs is a lot nicer to use from a human interface point of view (and the merging is really a lot nicer), but the nicest thing about arch is that a given commit is immutable. There are no tools to modify it. This is also why the crypto signature stuff was so easy to fit in. RCS and SCCS storage throws away most of those features. -- Dustin Sallings - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Fri, Feb 18, 2005 at 02:52:20AM -0500, Sean wrote: > There are ways that the tools could coexist and work together better than > they do today. If people would stop acting like BK was in jeopardy of > being taken away from them and realize that others just want the ability > to use their tools of choice too. If you truly believe that BK would be able to add the value that it does to the kernel development process by using some other SCM as the master SCM, with BK being "underneath", as you proposed earlier, then you do not understand why BK is fundamentally better than the current open source SCM systems that are out there. And people *can* use the tools of their choice today. They can use CVS, and diff+patch, and suffer with all of the limitations that those tools have today. And for people who are doing stuff around the periphery, quilt is often really the best tool for them. > > Linus clearly considered not just his /own/ workflow, but the workflow > > for the /whole/ kernel development community. In fact, BK was designed > > Well, the /whole/ community isn't yet included, that's what we're talking > about. If it's about the whole ***kernel*** development community, then it's pretty clear that the current system works quite well. All of the complaints have been coming primarily from SCM hackers, it seems, and not people who truly need the power of more powerful than downloading the bk snapshots, using the CVS export tree, and in the case where they need to look at the changes in a single changeset bkbits.net. The "cost" of using BK seems to be primarily more theoretical, and ideological, than real. It's always seems to be about someone kvetching that they want to use SVN and get finely grained changsets through SVN, and they can't. But how often does that happen, and what's so painful of getting the finely grained changeset through bkbits.net? Not very. So at the end of the day, it finally boils down to being all about ideology, doesn't it? Once again proving that Linus, as is often the case, was right all along. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote: > RCS/SCCS format doesn't make much sence for a changeset oriented SCM. The advantage it will provide is that it'll be compact and a backup will compress at best too. Small compressed tarballs compress very badly instead, it wouldn't be even comparable. Once the thing is very compact it has a better chance to fit in cache, and if it fits in cache extracting diffs from each file will be very fast. Once it'll be compact the cost of a changeset will be diminished allowing it to scale better too. Now it's true new disks are bigger, but they're not much faster, so if the size of the repository is much larger, it'll be much slower to checkout if it doesn't fit in cache. And if it's smaller it has better chances of fitting in cache too. The thing is, RCS seems a space efficient format for storing patches, and it's efficient at extracting them too (plus it's textual so it's not going to get lost info even if something goes wrong). The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed. My suggestion is to convert _all_ dozen thousand changesets to arch or SVN and then compare the size with CVS (also the compressed size is interesting for backups IMHO). Unfortunately I know nothing about darcs yet (except it eats quite some memory ;) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Friday 18 February 2005 02:26, Sean wrote: > On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said: > > > If you think that, you truly do not understand the value of BK, and > > why Linus chose it. > > Hey Ted, > > No, I just disagree that it was an absolute requirement or worth its cost > that so many want to completely discount. Andrew has pretty much shown > BK is not required, he's still using patches. Andrew uses BK too. He extends its function by maintaining a set of patches above and beyond the committed BK tree... Ted made a really valid point. The people at the top _are_ _very_ _very_ important. There are several ways to get kernel source if _you_ do not want to use BK. I use BK. There are enough projects around that I can avoid working on a SVM for a year... Thats my option though - you do not have to agree. Ed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Fri, 18 Feb 2005 10:09:00 +0100, Andrea Arcangeli <[EMAIL PROTECTED]> wrote: > On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote: > > small to medium sized ones). Last I checked, Arch was still too slow in > > some areas, though that might have changed in recent months. Also, many > > IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the > backend and a single file for the changesets and with sane parameters > conventions miming SVN. RCS/SCCS format doesn't make much sence for a changeset oriented SCM. /Erik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Fri, Feb 18, 2005 at 10:09:00AM +0100, Andrea Arcangeli wrote: > darcs scares me a bit because it's in haskell, I don't believe very much > in functional languages for compute intensive stuff, ram utilization > skyrockets sometime (I wouldn't like to need >1G of ram to manage the > tree). AFAICS, most of memory related problems in darcs are not necessarily a result of using Haskell. > Other languages like python or perl are much slower than C/C++ too but > at least ram utilization can be normally dominated to sane levels with > them and they can be greatly optimized easily with C/C++ extensions of > the performance critical parts. With those languages, you often have no other choice than resorting to C. GHC is quite a good compiler and I've often been able to get my programs run almost as fast as programs written in C++ - however, if I were to write those programs in C++, I would never do that, despite being quite a good C++ programmer. Also, in Haskell you can use extensions written in C, as easily or even easier than in Python or Perl (I've done this in Perl, heard the battle stories about C extensions in Python). Haskell's FFI is quite good, there are also many supporting tools. Best regards Tomasz -- Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote: > small to medium sized ones). Last I checked, Arch was still too slow in > some areas, though that might have changed in recent months. Also, many IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the backend and a single file for the changesets and with sane parameters conventions miming SVN. The internal algorithms of arch seems the most advanced possible. It's just the interface and the fs backend that's so bad and doesn't compress in the backups either. SVN bsddb doesn't compress either by default, but at least the new fsfs compresses pretty well, not as good as CVS, but not as badly as bsddb and arch either. I may be completely wrong, so take the above just as a humble suggestion. darcs scares me a bit because it's in haskell, I don't believe very much in functional languages for compute intensive stuff, ram utilization skyrockets sometime (I wouldn't like to need >1G of ram to manage the tree). Other languages like python or perl are much slower than C/C++ too but at least ram utilization can be normally dominated to sane levels with them and they can be greatly optimized easily with C/C++ extensions of the performance critical parts. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote: > were employed by bitmover, or signed an NDA to look at the code. But > just the act of using it is ridicules. Can you see Ford Motors telling > someone that you can't go work for GM if you drive a Ford? Your point makes sense to me too, but really, this 1 year delay is nothing compared to the previous status, so this is a great improvement. The previous licence was not enforceable in Germany and I guess in Italy too, but really seeing so many other people using a product with such a licence and without any care (even if void) was unbearable to me. Now the new licence may still not be enforceable, but I don't care anymore, because even if it's enforceable by bad luck, it would be bearable to wait 1 year. Switching SCM is a costly operation regardless. This time limit has been declared for the first time ever, and this is a great news, so now the FUD is over. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 12:05:44PM -0800, Larry McVoy wrote: > That's not how others are reading it and when we requested clarification > from the legal firm we use for contracts (Fenwick&West if you care) they > said that it could well be interpreted that if you use BK you are giving > up your right to hack on another system. That wasn't our intent but nor You know I'm not a lawyer but that's exactly the way I read it too: http://lkml.org/lkml/2004/10/25/224 http://lkml.org/lkml/2004/10/25/400 http://lkml.org/lkml/2004/10/25/249 I've been too harsh in the past on this, but the no time limit was unbearable to me, and finally some sanity showed up today and things become bearable for the first time ever as far as I'm concerned. Now it seems that many folks misunderstood the old licence if they're complaining about the licence change. Complaints about the new licence are a no sense as far as I can see. I'm only amazed you didn't clarify this earlier if your intention was really to allow hacking on other systems after a certain amount of time. You had ton of chances to clarify it before the layers lined things up, including in answer to the above messages. Anyway I don't care since a clarification by email wouldn't been enough as far as I was concerned, so I'm glad eventually the licence is changing. A big thanks to Fenwick&West from my part. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 8:42 pm, Horst von Brand said: > Linus clearly considered not just his /own/ workflow, but the workflow > for the /whole/ kernel development community. In fact, BK was designed Well, the /whole/ community isn't yet included, that's what we're talking about. > around the requirements Linus and other head hackers laid down for a > SCM for use in Linux. And I'm quite sure that if Linus et al had > serious misgivings about the license somehow hindering Linux > development, they would have got it fixed or dumped BK. Linus has > said time and again that he just cares for the very best kernel > possible, nothing else. Do you think that the developers who must or want to use other SCM tools desire less? > Sure, from the periphery of kernel development using something else looks > simple. But you have to consider there are literaly dozens of trees (of > the head maintainers) exchanging changesets. The flow of going into > 2.6 is astonishing right now, I'd say some 3 or 5 times more than > what got into the most furious 2.3 patch frenzies. Existing open > source tools just aren't up to the task, as Linus has repeatedly said. There are ways that the tools could coexist and work together better than they do today. If people would stop acting like BK was in jeopardy of being taken away from them and realize that others just want the ability to use their tools of choice too. > Just now there are starting to be halfways useful SCM systems (almost > all based on the "one central repository" idea, which doesn't cut it > for Linux), but they aren't proven enough. Yeah, there are some glimmers of hope for sure, but you're right they're a ways off. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said: > If you think that, you truly do not understand the value of BK, and > why Linus chose it. Hey Ted, No, I just disagree that it was an absolute requirement or worth its cost that so many want to completely discount. Andrew has pretty much shown BK is not required, he's still using patches. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
"Sean" <[EMAIL PROTECTED]> said: > On Thu, February 17, 2005 3:52 pm, Horst von Brand said: [...] > > "Best tool for the job" certainly includes minutiae like "benefits" and > > "price". > Thank you, that's my point. It's not just about the geeky microscopic > technical details. Linus clearly considered not just his /own/ workflow, but the workflow for the /whole/ kernel development community. In fact, BK was designed around the requirements Linus and other head hackers laid down for a SCM for use in Linux. And I'm quite sure that if Linus et al had serious misgivings about the license somehow hindering Linux development, they would have got it fixed or dumped BK. Linus has said time and again that he just cares for the very best kernel possible, nothing else. Sure, from the periphery of kernel development using something else looks simple. But you have to consider there are literaly dozens of trees (of the head maintainers) exchanging changesets. The flow of going into 2.6 is astonishing right now, I'd say some 3 or 5 times more than what got into the most furious 2.3 patch frenzies. Existing open source tools just aren't up to the task, as Linus has repeatedly said. Just now there are starting to be halfways useful SCM systems (almost all based on the "one central repository" idea, which doesn't cut it for Linux), but they aren't proven enough. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Clemens Schwaighofer <[EMAIL PROTECTED]> said: > On 02/17/2005 01:57 PM, Theodore Ts'o wrote: > > Compare the number of developers, the number of overlapping > > simultaneous development trees, and the number of patches that touch > > overlapping files, and you'll begin to start to appreciate the > > difference between a system that can work for Linux, and a system that > > can working for simpler projects. > apache might be simpler, but I doubt that for gcc. But well lets see > what the gcc guys will decide. gcc has very much less developers than the kernel. It has worked for years around CVS' shortcommings, plus being a core GNU package, it is quite unlikely to /ever/ go for a non-oss SCM. Plus the bureaucracy (have to have a paper signing over ownership to the FSF for any changes) make a fully Linux-style development unlikely (and thus BK (which was designed as SCM for the kernel) not really useful). -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/18/2005 01:00 PM, Theodore Ts'o wrote: > On Thu, Feb 17, 2005 at 06:32:04PM -0500, Sean wrote: > >>No. It's about recognizing the needs of more people than just the few at >>the top. Besides, with a free tool at the Head, bk could continue to be >>used underneath by Linus and anyone else. > > > If you think that, you truly do not understand the value of BK, and > why Linus chose it. He choose it because it was the best tool to do the job at that time. It might still be the best job to do it. But for a normal user, who just wants to check out certain bk pulls, the new license is not bearable. I think we need a SVN mirror here soon, very soon. - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFWkcjBz/yQjBxz8RAm5IAKDERXzaCeh1Qcuipp3sjZXxC7/DwgCgpl63 YgVM09sYczPMJsedObgKkLI= =8vFK -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, Feb 17, 2005 at 06:32:04PM -0500, Sean wrote: > No. It's about recognizing the needs of more people than just the few at > the top. Besides, with a free tool at the Head, bk could continue to be > used underneath by Linus and anyone else. If you think that, you truly do not understand the value of BK, and why Linus chose it. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
On Thu, February 17, 2005 9:24 pm, Tupshin Harper said: Hi Tupshin, > Speaking as somebody that uses Darcs evey day, my opinion is that the > future of OSS SCM will be something like arch or darcs but that neither > are ready for projects the size of the linux kernel yet. Darcs is > definitely way too slow for really large projects (though great for > small to medium sized ones). Last I checked, Arch was still too slow in > some areas, though that might have changed in recent months. Also, many > people, me included, find the usability of arch to be from ideal. > > My hope and expectation is that Arch and Darcs will both improve their > performance, features, and usability and that in the not too distant > future both of them will be viable alternatives for large scale source > tree management. Falling into the same category probably is svk, although it's less mature than the options you cite. > The important thing for the health of the SCM ecosystem is that there be > ways to losslessly convert and interoperate between them as well as > between legacy/centralized systems such as CVS and SVN as well as with > BK. Amen. Thanks, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [darcs-users] Re: [BK] upgrade will be needed
Patrick McFarland wrote: On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote: Something that unintentionally started a flamewar. Well, we just went through another round of 'BK sucks' and 'BK sucks, we need to switch to something else'. Sans the flamewar, are there any options? CVS and SVN are out because they do not support 'off server' branches (arch and darcs do). Darcs would probably be the best choice because its easy to use, and the darcs team almost has a working linux-kernel import script (originally designed to just test darcs with a huge repo, but provides a mostly working linux tree). So, without the flamewar, what is everyone's opinion on this? Speaking as somebody that uses Darcs evey day, my opinion is that the future of OSS SCM will be something like arch or darcs but that neither are ready for projects the size of the linux kernel yet. Darcs is definitely way too slow for really large projects (though great for small to medium sized ones). Last I checked, Arch was still too slow in some areas, though that might have changed in recent months. Also, many people, me included, find the usability of arch to be from ideal. My hope and expectation is that Arch and Darcs will both improve their performance, features, and usability and that in the not too distant future both of them will be viable alternatives for large scale source tree management. The important thing for the health of the SCM ecosystem is that there be ways to losslessly convert and interoperate between them as well as between legacy/centralized systems such as CVS and SVN as well as with BK. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Sunday 13 February 2005 09:08 pm, Larry McVoy wrote: > Something that unintentionally started a flamewar. Well, we just went through another round of 'BK sucks' and 'BK sucks, we need to switch to something else'. Sans the flamewar, are there any options? CVS and SVN are out because they do not support 'off server' branches (arch and darcs do). Darcs would probably be the best choice because its easy to use, and the darcs team almost has a working linux-kernel import script (originally designed to just test darcs with a huge repo, but provides a mostly working linux tree). So, without the flamewar, what is everyone's opinion on this? -- Patrick "Diablo-D3" McFarland || [EMAIL PROTECTED] "Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music." -- Kristian Wilson, Nintendo, Inc, 1989 pgpAuhopI9PLP.pgp Description: PGP signature
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 07:27 PM, Sean wrote: > On Thu, February 17, 2005 4:27 am, Roland Kuhn said: > > >>The difference comes after the merge. Suppose Andrew didn't push >>everything to Linus. Then new patches come in, both trees change. In >>this situation it is very time consuming with subversion to work out >>the changes which still have to go from Andrew's tree to Linus' tree. > > > Since Andrew does this all by hand now, subversion / arch / whatever could > only improve the situation. And the kicker is that using a free system > would mean the result could be dumped into BK for those that want to use > it. The reverse unfortunately isn't true; not because of technical > reasons, but because of license restrictions. well I think Andrew will have tonsof small helper scripts for that. I doubt he has time to try out various vcs ... (especially if they are so complicated to use like arch). - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFTecjBz/yQjBxz8RAqx5AJ9TCxTpvXkfnUbGiPM67VQsa5RVlwCeMXPR 9RPlx/090x7ALlctuvSnWo4= =9Xst -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 01:57 PM, Theodore Ts'o wrote: > Compare the number of developers, the number of overlapping > simultaneous development trees, and the number of patches that touch > overlapping files, and you'll begin to start to appreciate the > difference between a system that can work for Linux, and a system that > can working for simpler projects. apache might be simpler, but I doubt that for gcc. But well lets see what the gcc guys will decide. - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFTb7jBz/yQjBxz8RAqK+AJ9qyQaqg/zQz/xt6XKpLjlJIC5u9gCbBrPg D/3yjB5iv7HCSMtVOIZx6Xo= =Zfsd -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 6:54 pm, Lee Revell said: > Ed did not say it was a choice between BK and nothing. He said "Linus > has tried other SCMs. They did not suffice." Did you even read his > comment? The point you missed is that it's not an honest comparison to look at the post BK/ pre BK situation and pretend that BK was the only option that would have produced the list of benefits that Ed outlined. Linus has been known to be wrong before. > Please don't cc: me on this thread anymore, unless it's about some work > you did to bring BK functionality to a free SCM. No need to respond. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, 2005-02-17 at 18:32 -0500, Sean wrote: > On Thu, February 17, 2005 6:25 pm, Ed Tomlinson said: > > Linus has tried other SCMs. They did not suffice. I remember the preBK > > days, when you had to post a patch half a dozen time to get it merged. > > Patches were being missed left right and center. This changed after BK. > > We _are_ getting large benefits from BK. They may be hard to see at our > > side of the keyboard - but I believe Linus when he says BK is the best > > tool for him. That this probably will not be the case for ever. Think > > it still is for now though. > > It's not a choice between BK or nothing. Much of the improvements you're > attributing to BK would have been realized with any other SCM system too. > Ed did not say it was a choice between BK and nothing. He said "Linus has tried other SCMs. They did not suffice." Did you even read his comment? Please don't cc: me on this thread anymore, unless it's about some work you did to bring BK functionality to a free SCM. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 6:25 pm, Ed Tomlinson said: >> Yes, I do remember that post. But i'm not arguing from an ideological >> basis; i'm arguing on practical grounds that the price of using BK is >> too >> high for its supposed benefits. I've not seen anyone else make that > > Huh? This ideology in my books. No. It's about recognizing the needs of more people than just the few at the top. Besides, with a free tool at the Head, bk could continue to be used underneath by Linus and anyone else. And others in the community could use their preferred tools too. > Linus has tried other SCMs. They did not suffice. I remember the preBK > days, when you had to post a patch half a dozen time to get it merged. > Patches were being missed left right and center. This changed after BK. > We _are_ getting large benefits from BK. They may be hard to see at our > side of the keyboard - but I believe Linus when he says BK is the best > tool for him. That this probably will not be the case for ever. Think > it still is for now though. It's not a choice between BK or nothing. Much of the improvements you're attributing to BK would have been realized with any other SCM system too. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thursday 17 February 2005 11:58, Sean wrote: > On Thu, February 17, 2005 11:55 am, Chris Friesen said: > > > If you look at the archives, there have been a *lot* of people saying > > very much the same thing as you. I suspect people are getting tired of > > giving the same responses all the time. > > > > Here is what Linus had to say about it a while back: > > > > If people in the open-source SCM community wake up and notice that > > the current open-source SCM systems aren't cutting it, that's _good_. > > But it's absolutely NOT an excuse to use them today. Sorry. I use > > CVS at work, and I could never use it for Linux. I took a look at > > subversion, and it doesn't even come close to what I wanted. > > > > And I personally refuse to use inferior tools because of ideology. In > > fact, I will go as far as saying that making excuses for bad tools > > due to ideology is _stupid_, and people who do that think with their > > gonads, not their brains. > > Chris, > > Yes, I do remember that post. But i'm not arguing from an ideological > basis; i'm arguing on practical grounds that the price of using BK is too > high for its supposed benefits. I've not seen anyone else make that Huh? This ideology in my books. > argument here on the list and it is something that Linus may not have > given full consideration to. At least the comment that you quote gives > no consideration to it at all. Linus has tried other SCMs. They did not suffice. I remember the preBK days, when you had to post a patch half a dozen time to get it merged. Patches were being missed left right and center. This changed after BK. We _are_ getting large benefits from BK. They may be hard to see at our side of the keyboard - but I believe Linus when he says BK is the best tool for him. That this probably will not be the case for ever. Think it still is for now though. Ed Tomlinson - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
* David Weinehall ([EMAIL PROTECTED]) wrote: > BTW: Wishlist request. Would you consider adding -p (--show-c-function) > to the set of flags used for the diffs created by BitKeeper? It's already there. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 3:52 pm, Horst von Brand said: > "Best tool for the job" certainly includes minutiae like "benefits" and > "price". Thank you, that's my point. It's not just about the geeky microscopic technical details. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
"Sean" <[EMAIL PROTECTED]> said: > On Thu, February 17, 2005 11:55 am, Chris Friesen said: > > If you look at the archives, there have been a *lot* of people saying > > very much the same thing as you. I suspect people are getting tired of > > giving the same responses all the time. > > > > Here is what Linus had to say about it a while back: > > > > If people in the open-source SCM community wake up and notice that > > the current open-source SCM systems aren't cutting it, that's _good_. > > But it's absolutely NOT an excuse to use them today. Sorry. I use > > CVS at work, and I could never use it for Linux. I took a look at > > subversion, and it doesn't even come close to what I wanted. > > > > And I personally refuse to use inferior tools because of ideology. In > > fact, I will go as far as saying that making excuses for bad tools > > due to ideology is _stupid_, and people who do that think with their > > gonads, not their brains. > Yes, I do remember that post. But i'm not arguing from an ideological > basis; i'm arguing on practical grounds that the price of using BK is too > high for its supposed benefits. "Best tool for the job" certainly includes minutiae like "benefits" and "price". > I've not seen anyone else make that > argument here on the list and it is something that Linus may not have > given full consideration to. At least the comment that you quote gives > no consideration to it at all. It doesn't do so overtly, no. Doesn't mean it wasn't part of the equation. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 09:12:19AM -0800, Larry McVoy wrote: > > >So how would you suggest that we resolve it? The protection we need is > > >that people don't get to > > > > > > - use BK > > > - stop using BK so they can go work on another system > > > - start using BK again > > > - stop using BK so they can go work on another system > > > > What??? Why not? BK is a PROGRAM. You can't tell somebody > > that once they use some program in one job, they can't > > use it again. What kind of "protection" are you claiming? > > It is a program that comes with a license. Licenses have terms which > survive the termination of the license, that's industry standard, they > all have such terms. > > In this case the situation is unusual because we have a program that is > ahead, in some ways, of all the other programs out there that do the > same thing. We'd like to protect that lead. We put that lead at risk > by giving you BK for free, that's more or less suicide because the open > source world has a long track record of copying that which they find > useful. We don't want you to copy it. If you can't agree to not copy > it then you don't get to use it in the first place. Does these license terms (the ones concerning developing competing software while, or within a year of, using BK) also apply to the commercial license? BTW: Wishlist request. Would you consider adding -p (--show-c-function) to the set of flags used for the diffs created by BitKeeper? Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 11:55 am, Chris Friesen said: > If you look at the archives, there have been a *lot* of people saying > very much the same thing as you. I suspect people are getting tired of > giving the same responses all the time. > > Here is what Linus had to say about it a while back: > > If people in the open-source SCM community wake up and notice that > the current open-source SCM systems aren't cutting it, that's _good_. > But it's absolutely NOT an excuse to use them today. Sorry. I use > CVS at work, and I could never use it for Linux. I took a look at > subversion, and it doesn't even come close to what I wanted. > > And I personally refuse to use inferior tools because of ideology. In > fact, I will go as far as saying that making excuses for bad tools > due to ideology is _stupid_, and people who do that think with their > gonads, not their brains. Chris, Yes, I do remember that post. But i'm not arguing from an ideological basis; i'm arguing on practical grounds that the price of using BK is too high for its supposed benefits. I've not seen anyone else make that argument here on the list and it is something that Linus may not have given full consideration to. At least the comment that you quote gives no consideration to it at all. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Sean wrote: Your cookie cutter response, proves you didn't really absorb the content of my message. Please reread; there was no "bitching" at all. If you look at the archives, there have been a *lot* of people saying very much the same thing as you. I suspect people are getting tired of giving the same responses all the time. Here is what Linus had to say about it a while back: If people in the open-source SCM community wake up and notice that the current open-source SCM systems aren't cutting it, that's _good_. But it's absolutely NOT an excuse to use them today. Sorry. I use CVS at work, and I could never use it for Linux. I took a look at subversion, and it doesn't even come close to what I wanted. And I personally refuse to use inferior tools because of ideology. In fact, I will go as far as saying that making excuses for bad tools due to ideology is _stupid_, and people who do that think with their gonads, not their brains. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 11:34 am, Lee Revell said: > If you don't like it you are free to write a better SCM that is free > software. I am sure if you brought Linus a free software SCM that's as > good as BK he would use it. Bitching about it on LKML will not get you > any closer to having said SCM. Lee, Your cookie cutter response, proves you didn't really absorb the content of my message. Please reread; there was no "bitching" at all. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, 2005-02-17 at 01:49 -0500, Sean wrote: > The affects of many top level folks using a non free system is felt all > the way down the food-chain. If the top tier would agree to use a free > SCM system then we could build bridges and offer the data in the preferred > format to _everyone_ (arch, subversion, patch, BK, etc). But because BK > is used at the top, many useful options are cut off. It's a rather large > "hidden" cost of BK adoption as the primary tool at the top. If you don't like it you are free to write a better SCM that is free software. I am sure if you brought Linus a free software SCM that's as good as BK he would use it. Bitching about it on LKML will not get you any closer to having said SCM. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
* Geert Uytterhoeven: >> Easy, start working for OSDL, then start hacking arch or >> whatever. Puff, you are his coworker, you are competing with Larry, >> Linus license goes away. > > I don't know whether the kernel hackers that work for IBM use the > `free' version of BK or not, but if they do, s/OSDL/IBM/ and > s/arch/ClearCase/ and there's a problem... No, there isn't. Bitmover can choose freely against whom they try to enforce their copyright licenses. Copyright law is not like trademark law. You can selectively enforce your rights without risking dilution. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, Feb 17, 2005 at 10:46:41AM +0100, Geert Uytterhoeven wrote: > I don't know whether the kernel hackers that work for IBM use the `free' > version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and > there's a problem... No, there's not a problem. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, Feb 17, 2005 at 01:36:03PM +0100, Citizen Number 52642 wrote: > > > Easy, start working for OSDL, then start hacking arch or > > > whatever. Puff, you are his coworker, you are competing with Larry, > > > Linus license goes away. > > > > I don't know whether the kernel hackers that work for IBM use the `free' > > version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and > > there's a problem... > > Actually someone should show the license agreement to IBM (and Novell, > for that matter) lawyers. I guess next thing would be company-wide > search-and-destroy aimed at bitkeeper ;-). I think this attitude is completely rediculous. What you are suggesting is taking away peoples right to choose to use BitKeeper if they decide that it fits what they want to use it for, and that they can live with the license terms (and/or have a special agreement with BitMover for that purpose.) Sure, that sounds exactly like a free world, Citizen Number 52642. -- Citizen Number 24655 Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Hi! > > Easy, start working for OSDL, then start hacking arch or > > whatever. Puff, you are his coworker, you are competing with Larry, > > Linus license goes away. > > I don't know whether the kernel hackers that work for IBM use the `free' > version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and > there's a problem... Actually someone should show the license agreement to IBM (and Novell, for that matter) lawyers. I guess next thing would be company-wide search-and-destroy aimed at bitkeeper ;-). Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 4:27 am, Roland Kuhn said: > The difference comes after the merge. Suppose Andrew didn't push > everything to Linus. Then new patches come in, both trees change. In > this situation it is very time consuming with subversion to work out > the changes which still have to go from Andrew's tree to Linus' tree. Since Andrew does this all by hand now, subversion / arch / whatever could only improve the situation. And the kicker is that using a free system would mean the result could be dumped into BK for those that want to use it. The reverse unfortunately isn't true; not because of technical reasons, but because of license restrictions. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, 17 Feb 2005, Pavel Machek wrote:
> > >> if they really need the more powerful features. Or we could donate
> > >> some on a case by case basis.
> > >>
> > >> If the hackers who are using BK can reach agreement that it would be
> > >> better if the BK they had didn't move forward unless they got commercial
> > >> seats then we could start moving towards a license on the free product
> > >> that was less restrictive. What that would mean is that the BK you have
> >
> > > I want to pay the fee for Linus and Alan.
> >
> > I'd like to pay the fee to have Linus' license to use BK revoked. But
> > I probably can't afford it, oh well :-)
>
> Easy, start working for OSDL, then start hacking arch or
> whatever. Puff, you are his coworker, you are competing with Larry,
> Linus license goes away.
I don't know whether the kernel hackers that work for IBM use the `free'
version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
there's a problem...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Hi Clemens! On Feb 17, 2005, at 9:09 AM, Clemens Schwaighofer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 04:55 PM, Roland Kuhn wrote: That said, it would of course be possible to improve the internal workflow of our emperor penguin if he used subversion, but the collaboration with others could not benefit the way it does with a changeset-based approach. Question is then, what about keeping a main trunk with the vanialle release, and each dev has its own branch. now at a certain point you have to merge them. Now where is the difference between a central rep and a de-central one. At day X, patches from Andrew's tree have to go to Linus tree and from his tree into the new vanialla kernel. right? Somehow I can't see the difference here. The difference comes after the merge. Suppose Andrew didn't push everything to Linus. Then new patches come in, both trees change. In this situation it is very time consuming with subversion to work out the changes which still have to go from Andrew's tree to Linus' tree. Ciao, Roland -- TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching Telefon 089/289-12592; Telefax 089/289-12570 -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. PGP.sig Description: This is a digitally signed message part
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 04:55 PM, Roland Kuhn wrote: > That said, it would of course be possible to improve the internal > workflow of our emperor penguin if he used subversion, but the > collaboration with others could not benefit the way it does with a > changeset-based approach. Question is then, what about keeping a main trunk with the vanialle release, and each dev has its own branch. now at a certain point you have to merge them. Now where is the difference between a central rep and a de-central one. At day X, patches from Andrew's tree have to go to Linus tree and from his tree into the new vanialla kernel. right? Somehow I can't see the difference here. > Linux kernel development is hard _and_ sexy :-) at least something :D - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCFFEojBz/yQjBxz8RAs5rAKC1i4RuDxyi3hjnRDfcjCYyRTGbNQCgsRgc ErnefDIDGimPjjXa8cALBQc= =lWQ8 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Hi Clemens! On Feb 17, 2005, at 1:11 AM, Clemens Schwaighofer wrote: first. what kind of advantages does bk have over other svn? Seriously. If Apache can use it, and gcc might use it (again two very large projects), what makes linux so differetnt that it can't. And I don't want _anything_ from Larry. I am just pointing out, that this kind of legal clause is more ridicolous than understandable. Well, I'm obviously not Larry, so here are my 2ct: Subversion is superior to CVS in all respects, but that is not an overly strong statement. The main problem is that it is centralized in a way that hinders the parallel existence of development branches because it does not properly support the shuffling of changes back and forth between trees. It all works fine until you want to _partially_ synchronize two trees and keep the ability to continue development on both of them. (Been there, done that, it was a major PITA even in a rather small project. Works fine for my PhD thesis, though ;-) ) That said, it would of course be possible to improve the internal workflow of our emperor penguin if he used subversion, but the collaboration with others could not benefit the way it does with a changeset-based approach. Last, why can you compare cvs to bk? and not subversion, or arch? arch and subversion are way superiour to cvs ... SCM is hard and not sexy, I'm afraid. yes its hard, so we have to use bk with a very strange license? better close the eyes and not change. What do you think is kernel coding? Walk in the park? Do you think all those developers say, nah I better use Windows or Mac OS X, because its hard and not sexy ... pah ... BS! Linux kernel development is hard _and_ sexy :-) Ciao, Roland -- TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching Telefon 089/289-12592; Telefax 089/289-12570 -- A mouse is a device used to point at the xterm you want to type in. Kim Alm on a.s.r. PGP.sig Description: This is a digitally signed message part
Re: [BK] upgrade will be needed
On Thu, February 17, 2005 1:22 am, d.c said: > Do like them, ignore BK and continue using patch & diff. BK is just a > option, It doesn't stops you from developing in the linux kernel, I > can't understand why people cares so much about BK. The affects of many top level folks using a non free system is felt all the way down the food-chain. If the top tier would agree to use a free SCM system then we could build bridges and offer the data in the preferred format to _everyone_ (arch, subversion, patch, BK, etc). But because BK is used at the top, many useful options are cut off. It's a rather large "hidden" cost of BK adoption as the primary tool at the top. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
El Thu, 17 Feb 2005 00:57:55 -0500 (EST), "Sean" <[EMAIL PROTECTED]> escribió: > Even today, some top developers do not use BK and manage to get along Do like them, ignore BK and continue using patch & diff. BK is just a option, It doesn't stops you from developing in the linux kernel, I can't understand why people cares so much about BK. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Wed, February 16, 2005 11:57 pm, Theodore Ts'o said: > On Thu, Feb 17, 2005 at 09:11:45AM +0900, Clemens Schwaighofer wrote: >> >> first. what kind of advantages does bk have over other svn? Seriously. >> If Apache can use it, and gcc might use it (again two very large >> projects), what makes linux so differetnt that it can't. > > Compare the number of developers, the number of overlapping > simultaneous development trees, and the number of patches that touch > overlapping files, and you'll begin to start to appreciate the > difference between a system that can work for Linux, and a system that > can working for simpler projects. > Hey Ted, Considering that the kernel was being developed without BK for a long time it's rather obvious that _any_ version control system could have improved the situation. BK gets credit for improving the situation, but much of that improvment could have been achieved with any of the simpler and truly free options too. Even today, some top developers do not use BK and manage to get along fine. BK offers some advantages over simpler version control offerings but the price is too high. It's disappointing to see so many top developers not give a damn about its costs and ignore the difficulties it creates for many. Cheers, Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Thu, Feb 17, 2005 at 09:11:45AM +0900, Clemens Schwaighofer wrote: > > first. what kind of advantages does bk have over other svn? Seriously. > If Apache can use it, and gcc might use it (again two very large > projects), what makes linux so differetnt that it can't. Compare the number of developers, the number of overlapping simultaneous development trees, and the number of patches that touch overlapping files, and you'll begin to start to appreciate the difference between a system that can work for Linux, and a system that can working for simpler projects. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Feb 16, 2005, Pavel Machek <[EMAIL PROTECTED]> wrote: >> > I want to pay the fee for Linus and Alan. >> I'd like to pay the fee to have Linus' license to use BK revoked. But >> I probably can't afford it, oh well :-) > Easy, start working for OSDL, then start hacking arch or > whatever. Puff, you are his coworker, you are competing with Larry, > Linus license goes away. Hey, cool! The nice thing is that I probably don't even have to start hacking anything, I already (pretend to) maintain GNU CVS Utilities. Can I volunteer to maintain is for OSDL, at no charge? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 12:39 AM, d.c wrote: > El Wed, 16 Feb 2005 18:45:27 +0900, > Clemens Schwaighofer <[EMAIL PROTECTED]> escribió: > > >>than mature VCS. Apache group is switching to it, gcc people are >>strongly thinking about it, and those two are _huge_ projects with tons >>of developers, patches, trunks, etc. > > > and all of them work today with CVS, so any SCM will fit their purposes. so, your point it is, because linux used none before, none than bk fit? - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCE+HpjBz/yQjBxz8RAr8lAJ4w6TK0c7H1fjs178Y9Q0Mr4hdGBgCg32cT LUSf7DWy++w+cczaHpeEnIs= =zRM5 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/17/2005 12:43 AM, Olivier Galibert wrote: >>Perhaps its about time, that linux also switches. > > > Think what you want of Larry, but SVN is nowhere near BK is term of > capabilities (and neither is arch for he matter). It's only better > compared to cvs, and then not by that much. first. what kind of advantages does bk have over other svn? Seriously. If Apache can use it, and gcc might use it (again two very large projects), what makes linux so differetnt that it can't. And I don't want _anything_ from Larry. I am just pointing out, that this kind of legal clause is more ridicolous than understandable. Last, why can you compare cvs to bk? and not subversion, or arch? arch and subversion are way superiour to cvs ... > SCM is hard and not sexy, I'm afraid. yes its hard, so we have to use bk with a very strange license? better close the eyes and not change. What do you think is kernel coding? Walk in the park? Do you think all those developers say, nah I better use Windows or Mac OS X, because its hard and not sexy ... pah ... BS! - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCE+FAjBz/yQjBxz8RAjgHAKDf03ccZzlYDaFcZtNyG5Do3pba0QCfQk31 R7mSvvgMI7IQ9C4/ahc0Hak= =L8t2 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Hi! > >> if they really need the more powerful features. Or we could donate > >> some on a case by case basis. > >> > >> If the hackers who are using BK can reach agreement that it would be > >> better if the BK they had didn't move forward unless they got commercial > >> seats then we could start moving towards a license on the free product > >> that was less restrictive. What that would mean is that the BK you have > > > I want to pay the fee for Linus and Alan. > > I'd like to pay the fee to have Linus' license to use BK revoked. But > I probably can't afford it, oh well :-) Easy, start working for OSDL, then start hacking arch or whatever. Puff, you are his coworker, you are competing with Larry, Linus license goes away. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Hi! > Those licenses don't care if you are competing with them or not, they > do a blanket do-not-reverse-engineer no matter who you are. We > tried Your license is way worse than standard do-not-reverse-engineer. Put standard do-not-reverse-engineer there and you'll see the screams going down... But I do not think you can prevent anyone giving their own data to anyone else with standard "do-not-reverse-engineer". Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Po 14-02-05 08:00:27, Larry McVoy wrote: > On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote: > > Can you see Ford Motors telling > > someone that you can't go work for GM if you drive a Ford? > > You paid for the Ford. Suppose Ford offered to give you the car but > said if you take it then you can't go work at GM because this car is > ahead of their technology. This is irelevant. Your license is illegal in big part of the world. You can just download bitkeeper and reverse engineer it in order to interoperate with it, no matter what Larry says; just check your local laws. To make the analogy: "You can stand on the street, giving people free Pepsi and telling them they are not allowed to drink Cola if they take Pepsi from you. And they can safely take Pepsi from you, drink it and laugh at you." Try it. Pavel -- People were complaining that M$ turns users into beta-testers... ...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 03:30:47PM -0600, Tom Felker wrote: > I really think the fewer restrictions you put on BK's use, the less likely it > will be copied. When the open source community copies something, it's not > out > of a desire to screw somebody over. It's because they had an itch, a > software need that couldn't easily be fulfilled otherwise, a demand. > > Apparently there is a demand for good SCM, and BK can satisfy this, and > you've > done the very admirable thing of letting the open source community use BK at > no cost. But by putting such a heavy restriction on its use, you create a > large portion of the community who won't or can't use it, and who therefore > need a "copy" of it, which is exactly what you are trying to prevent. I fully agree. Josef "Jeff" Sipek signature.asc Description: Digital signature
Re: [BK] upgrade will be needed
On Wed, February 16, 2005 10:43 am, Olivier Galibert said: > Think what you want of Larry, but SVN is nowhere near BK is term of > capabilities (and neither is arch for he matter). It's only better > compared to cvs, and then not by that much. > > SCM is hard and not sexy, I'm afraid. This has nothing to do with Larry personally. The point is that some people keep saying BK is better without stopping to think if the supposed advantages are honestly needed. They come with a rather large cost of reducing some people to second class participants and reducing the freedom to use collected metadata. Since svn or arch could fill the role quite nicely without these problems, it makes you wonder if the price of BK is too high for whatever advantage it provides over these other choices. Unfortunately the decision has already been made, so this is all academic. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
El Wed, 16 Feb 2005 18:45:27 +0900, Clemens Schwaighofer <[EMAIL PROTECTED]> escribió: > than mature VCS. Apache group is switching to it, gcc people are > strongly thinking about it, and those two are _huge_ projects with tons > of developers, patches, trunks, etc. and all of them work today with CVS, so any SCM will fit their purposes. > Perhaps its about time, that linux also switches. Linux kernel is patch + diff + announcement based (there's no need to use BK) I really would like it was different but... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Wed, Feb 16, 2005 at 06:45:27PM +0900, Clemens Schwaighofer wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/15/2005 09:19 PM, kernel wrote: > > > Just catching up on this thread. I guess I'm ultimately surprised that > > the developers here don't create a system *they* like with *their* > > knowledge and skillsets. > > > > With all of the complaining about BK you'd think there'd be an equal > > alternative. > > there is no need for that. There is already one. Subversion is a more > than mature VCS. Apache group is switching to it, gcc people are > strongly thinking about it, and those two are _huge_ projects with tons > of developers, patches, trunks, etc. > > Perhaps its about time, that linux also switches. Think what you want of Larry, but SVN is nowhere near BK is term of capabilities (and neither is arch for he matter). It's only better compared to cvs, and then not by that much. SCM is hard and not sexy, I'm afraid. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Catalin Marinas wrote: | Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: | |>On 02/15/2005 09:19 PM, kernel wrote: |> |>>With all of the complaining about BK you'd think there'd be an equal |>>alternative. |> |>there is no need for that. There is already one. Subversion is a more |>than mature VCS. Apache group is switching to it, gcc people are |>strongly thinking about it, and those two are _huge_ projects with tons |>of developers, patches, trunks, etc. | | | Subversion and BK are quite different. The first one is snapshot | oriented and the latter is changeset oriented (I find this a more | powerful concept). Subversion is not distributed (you have some helper | scripts but I don't know how stable they are), which is somehow | mandatory for the way Linux is developed. Subversion also lacks any | smart merging capabilities (it doesn't even remember what was | merged). | | GNU Arch is probably as close as you can get regarding features and | performance (I can't compare the two since I've never used BK). well yes, I never searched for a distributed VCS, thats why I never tried GNU Arch not so much (but I have to say, that it has hyper complex command line options, perhaps darcs might be better). Furthermore I sadly have to admit that I don't know the exact difference between snapshot and changeset oriented. I just know that subversion has ~ Atomic comits and it works more than fine for me :) Perhaps somebody can point me out to some Documentation about that (can be in PM and not to the list) lg, Clemens -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCE01KjBz/yQjBxz8RAgumAKDPg8I0hJU+rs/UIb0wRcgQy2dPOwCcDy6g 4994vMzy66WeTuB/fArYgMY= =Nyim -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Clemens Schwaighofer <[EMAIL PROTECTED]> wrote: > On 02/15/2005 09:19 PM, kernel wrote: >> With all of the complaining about BK you'd think there'd be an equal >> alternative. > > there is no need for that. There is already one. Subversion is a more > than mature VCS. Apache group is switching to it, gcc people are > strongly thinking about it, and those two are _huge_ projects with tons > of developers, patches, trunks, etc. Subversion and BK are quite different. The first one is snapshot oriented and the latter is changeset oriented (I find this a more powerful concept). Subversion is not distributed (you have some helper scripts but I don't know how stable they are), which is somehow mandatory for the way Linux is developed. Subversion also lacks any smart merging capabilities (it doesn't even remember what was merged). GNU Arch is probably as close as you can get regarding features and performance (I can't compare the two since I've never used BK). Catalin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
-BEGIN PGP SIGNED MESSAGE- (BHash: SHA1 (B (BOn 02/15/2005 09:19 PM, kernel wrote: (B (B> Just catching up on this thread. I guess I'm ultimately surprised that (B> the developers here don't create a system *they* like with *their* (B> knowledge and skillsets. (B> (B> With all of the complaining about BK you'd think there'd be an equal (B> alternative. (B (Bthere is no need for that. There is already one. Subversion is a more (Bthan mature VCS. Apache group is switching to it, gcc people are (Bstrongly thinking about it, and those two are _huge_ projects with tons (Bof developers, patches, trunks, etc. (B (BPerhaps its about time, that linux also switches. (B (B- -- (B[ Clemens Schwaighofer -=:~ ] (B[ TBWA\ && TEQUILA\ Japan IT Group ] (B[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] (B[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] (B[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] (B-BEGIN PGP SIGNATURE- (BVersion: GnuPG v1.2.6 (GNU/Linux) (BComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org (B (BiD8DBQFCExY2jBz/yQjBxz8RAlHAAJ9TqcN1ry1PYkZOqc5NF4JiVjbivwCgi79W (B6W1JMuOsX5hGvKFI3vL+NGU= (B=NM1T (B-END PGP SIGNATURE- (B- (BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in (Bthe body of a message to [EMAIL PROTECTED] (BMore majordomo info at http://vger.kernel.org/majordomo-info.html (BPlease read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Matthias Andree <[EMAIL PROTECTED]> writes: > > There'd be BK/Pro - a price list on the web for individual users might > be very helpful though. It won't be used very often but simplify the > decision process a bit. Yes, that would be an option, I'd rather spend money than limit my freedom. I'd need to check out the software first, which would be possible only if the restriction were reversed. JÃrgen -- NO to the planned nodding through of the EU software patent directive! JÃrgen Stuber <[EMAIL PROTECTED]> http://www.jstuber.net/ gnupg key fingerprint = 2767 CA3C 5680 58BA 9A91 23D9 BED6 9A7A AF9E 68B4 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
> > I want to pay the fee for Linus and Alan. > > I'd like to pay the fee to have Linus' license to use BK revoked. But > I probably can't afford it, oh well :-) Just write an SCM file system for the kernel and submit it to Linus. As to buying me a license, don't bother, and besides who knows what restrictions would magically appear in the next release Larry did. While Larry may well be a very friendly and well intentioned devil I'm still not making pacts with devils 8) The real fix is to replace BK with something free and better, but thats *not* a trivial task. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Mon, Feb 14, 2005 at 04:03:43PM -0800, Larry McVoy wrote: > And how does the CVS gateway not provide this today? The CVS gateway does not reach the rest of bkbits.net. For instance the ipw2200 tree since they miss some of the files in their tarball distribution. > And long ago I offered what I > called the tarball + patch server with an open source client for all > trees on bkbits.net Funnily enough the NWL probably isn't open-source because of the first clause. But frankly, it's irrelevant. > People didn't seem interested and I came with the conclusion, rightly or > wrongly, that the vast majority of the people who did real work didn't > care about the license and the noisy people just wanted to pick a fight. I read your mail as "you'll get that if and only the usual band stops whining", which obviously won't happen. Maybe I was wrong, I only know that at that point I can't get useful files from free projects hosted on bkbits if they're not the kernel itself. Your extension would indeed help. OG. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
Alexandre Oliva writes: >They can always pay for the non-free license to get that, I suppose. As far as I understand it, there are only non-free licences for Bitkeeper. For one you pay with money, for the other with freedom. While I am posting in this thread, I have a few questions to Larry McVoy: - You wrote that you could not develop Bitkeeper as free software, because it is economically not viable. You also write that you put the non-compete clause in the pay-with-freedom license, because you don't want to see a free clone of bitkeeper eat your business. So do you consider a free Bitkeeper-like system economically viable after all? - You say that all information is there, in the form of the patches. Could Bitkeeper reconstruct the Linux tree(s) from the patches alone? - anton -- M. Anton ErtlSome things have to be seen to be believed [EMAIL PROTECTED] Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Feb 15, 2005, [EMAIL PROTECTED] (Larry McVoy) wrote: > For those who don't know, bk changes -v is output in time sorted > order of changesets with the changeset comments then each file's > comments like the output below. > as Roman/Pavel/et al have pointed out sometimes the commits in the > CVS tree are too coarse if the cset you want is a merge of 20 > changesets on a branch. How would the `bk changes -v ' output look like for such a merge of 20 changesets on a branch? Would it list the 20 merged changesets? Also, would the changeset ids ([EMAIL PROTECTED]) match the revision IDs in the CVS tree? If so, it looks like this would provide the very bit of information that I feel to be missing from the publicly-available Linux repository. > But for people trying to easily track the head the tarball server might > be just the ticket. Any chance of having such tarballs offered from an rsync server, compressed with gzip --rsyncable? -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Feb 15, 2005, [EMAIL PROTECTED] (Larry McVoy) wrote: > The people we spoke with were far more interested in the ability to > move people onto BK when they needed to. They can always pay for the non-free license to get that, I suppose. -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Feb 14, 2005, Gerold Jury <[EMAIL PROTECTED]> wrote: >> if they really need the more powerful features. Or we could donate >> some on a case by case basis. >> >> If the hackers who are using BK can reach agreement that it would be >> better if the BK they had didn't move forward unless they got commercial >> seats then we could start moving towards a license on the free product >> that was less restrictive. What that would mean is that the BK you have > I want to pay the fee for Linus and Alan. I'd like to pay the fee to have Linus' license to use BK revoked. But I probably can't afford it, oh well :-) -- Alexandre Oliva http://www.ic.unicamp.br/~oliva/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org} - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
linux-os wrote: On Tue, 15 Feb 2005, kernel wrote: On Mon, 2005-02-14 at 13:56, Larry McVoy wrote: All we are trying to do is 1. Provide the open source community with a useful tool. 2. Prevent that from turning into the open source community creating a clone of our tool. lol I agree that this sucks, having a license that restricts your creativity is very annoying. On the other hand, you don't have to agree to it. Just catching up on this thread. I guess I'm ultimately surprised that the developers here don't create a system *they* like with *their* knowledge and skillsets. With all of the complaining about BK you'd think there'd be an equal alternative. For everyone not liking Larry nor BK, why don't you use that as inspiration to develop together a better app with terms more agreeable? Surely that would put a bit of vinegar in his p*ss, wouldn't it? -fd I have two questions for Larry. (1) If I use BK for company source-code development (purchased product, I didn't buy it, the company did and they require me to use it for my work) and I go to work for another company that also uses BK, your license says I can't use BK at the other company, which means that I can't work there. You can dislike the BK licencing all you want, but isn't there some misunderstandings here? I believe you can _use_ any SCM-system you want whenever you want. Using bitkeeper in one place does not prevent you from using it in another company also. Neither does using any other SCM. The limit lies in that you can't both use the *free* version of bitkeeper while also *developing* some other SCM. Note that the non-free bitkeeper, the one you pay for, is licenced differently. So if you use the *free* bitkeeper and some employer want you to work developing another SCM, then you have these options: 1. Quit the job because you cannot legally do it while using the free bitkeeper. 2. Quit using the free bitkeeper, by switching to another SCM for that project. 3. Quit using the free bitkeeper by purchasing a commercial licence for bitkeeper instead. So, you can have bitkeeper for free with a limiting license, or you can pay for an unencumbered bitkeeper. Or you can keep your money and not use bitkeeper, This is unlawful. How do you intend to enforce this? (2) If I use BK and I decide that I don't want to do business with you or the courts say that I have to return the software, will my source-code still be usable with, perhaps CVS? In other words do I need BK to retrieve my company's intellectual property? I don't really see the problem here - if they tell you to cease and desist using bitkeeper, then extract all your source first, before scrapping bitkeeper. Then install some other SCM and get the source tree into that. It is some work of course, but not a rewrite! Note that there is a little company (was a big company until the lawsuit), that used VOBS (container files) to store source- code. Seems that when the license expired, the users couldn't get their source code out. There was a lawsuit. Company lost (of course). Seems you can't hold somebody's intellectual property for ransom, at least in the United States. That's good. It should mean that nobody can prevent you from switching away from bitkeeper in an orderly fashion then. Helge Hafting - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Tue, 15 Feb 2005 02:46:04 +, Tristan Wibberley wrote: > On Mon, 14 Feb 2005 19:54:14 +0100, Juergen Stuber wrote: > >> g BK, I can immediately start working on another SCM >> but I can't go back to BK immediately > > IMHO, it should be the other way around, and more like two years. Hmm, I wasn't really clear here. I think that after using BK, you shouldn't be able to work on another SCM until 2 years have past. But you can shorten that time by paying bitmover 1/12 of a BK license for each month you want to shorten it. That covers the problem of people needing to switch, they just have to pay. Then the following applies: > Two years would be more > appropriate since you need to make sure that coders who've worked on the > other SCM before are well and truly out of touch with the code when they > go back. With that scheme, if you have a serious business case for > writing a new SCM *today* you just have to factor an extra cost into > your plans (double BK license), and if you want to work on an open > source one, you just have to wait while BitMover gets another two years > on their head-start. Now only people with determined plans can switch > from using BK to working on an SCM, and BitMover can get new users > benefiting from their kindness and lifting their market penetration as > easily as possible. -- Tristan Wibberley - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BK] upgrade will be needed
On Tue, 15 Feb 2005, kernel wrote: On Mon, 2005-02-14 at 13:56, Larry McVoy wrote: All we are trying to do is 1. Provide the open source community with a useful tool. 2. Prevent that from turning into the open source community creating a clone of our tool. lol I agree that this sucks, having a license that restricts your creativity is very annoying. On the other hand, you don't have to agree to it. Just catching up on this thread. I guess I'm ultimately surprised that the developers here don't create a system *they* like with *their* knowledge and skillsets. With all of the complaining about BK you'd think there'd be an equal alternative. For everyone not liking Larry nor BK, why don't you use that as inspiration to develop together a better app with terms more agreeable? Surely that would put a bit of vinegar in his p*ss, wouldn't it? -fd I have two questions for Larry. (1) If I use BK for company source-code development (purchased product, I didn't buy it, the company did and they require me to use it for my work) and I go to work for another company that also uses BK, your license says I can't use BK at the other company, which means that I can't work there. This is unlawful. How do you intend to enforce this? (2) If I use BK and I decide that I don't want to do business with you or the courts say that I have to return the software, will my source-code still be usable with, perhaps CVS? In other words do I need BK to retrieve my company's intellectual property? Note that there is a little company (was a big company until the lawsuit), that used VOBS (container files) to store source- code. Seems that when the license expired, the users couldn't get their source code out. There was a lawsuit. Company lost (of course). Seems you can't hold somebody's intellectual property for ransom, at least in the United States. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
