However, the original writer is missing a *very* important point. CVS branches are not simple and cheap. To branch, every,v file in the repository must be entirely rewritten to insert a couple tags at the front of the file.
Yeah, in that case I meant 'simple and cheap' in terms of storage overhead and not operational cost. Sorry. (Not sure - CVS might also require a full-repository lock to do that which is an even bigger issue than the read-write in a busy system.)
My question (as I've elaborated elsewhere) was about branching a subdirectory a few levels deep for my own development so I wasn't considering the cost of the branch operation.
I've sat down with the design doc again: my main worry is exactly section 8.1.3 ('User Interface for Branches and Tags' in 'Future'): my concern was that I couldn't make an experimental branch in the company-wide repository without it showing up at top-level and sparking 'what's that doing there?' witch-hunts.
Greg points out that branches can live under a '/branch/' root - which goes some way to addressing this if everyone's working against trunk, but if we're working on a branch as a matter of course (e.g. stabilising a release) then it doesn't really help.
My secondary concern is that I can't make an independent branch a few levels down, e.g.:
Say I wanted to work on a branch subprojectA1 but track trunk changes to subprojectsA2 and 3. This is trivial in CVS - tag and update subprojectA1 to the new tag, and then cvs update at top level works as I'd like. This may be possible by munging the SVN state directories but I don't see an obvious way of doing this automatically from the design doc.
A practical example of this might be the sources.redhat.com 'uberaum' repository which is combined from the GCC and binutils repositories; I don't know if it's as simple as symlinking the directories of,v files in the CVS case. However, I'm sure this could be accomplished in SVN by some sort of repository merge module in your layered architecture.
Still not sold on the revision numbering - automated whole-repository state is useful but bumping revision numbers and $Revision$ tags when the individual file hasn't changed will confuse non-savvy diff tools and, unless you preserve the date stamp, trigger unnecessary rebuilds (but then if the $Revision$ tag is in a string to compile-in then you *want* to trigger a rebuild - how to distinguish the two cases?). I think the dot-notation would have been useful to keep - it's obvious that 6.1 and 7.1 were branched from different parents whereas I'd have to do some svn operation to know that versions 35 and 38 were.
I might also miss the option of hand-hacking the,v files if I get myself in a particular mess - but, had I been using subversion instead, I probably wouldn't have had to.
One need only look at some of the problems large projects like GCC have with it to realize that some alternative is needed.
GCC's only problem, AFAICS, is the underlying RCS storage model: it's locking requirements, no central revision number store (for cheap no-change updates) and the patch-back-and-forwards operational cost of updating a branch.
I used Sourcesafe before I used CVS. One of the things that first impressed me with CVS was the branch model c.f. Sourcesafe's - specifically cheap, relatively unobtrusive/invisible branches: if I wanted to take one of our codebases and make my own experimental branch to hack around on then I can and it won't get questioned too much. I'm disappointed that subversion has adopted the Sourcesafe model but I confess I haven't studied the design docs to find out why. (I'm put off experimental-hack branches in the Sourcesafe model because they pollute the GUI.)
Was it truly anonymous? Given that this sort of thing is bound to get leaked, would they have embedded traitor identification in the memo? c.f. Yuval's "How to swindle Rabin", all they have to do is pick ten to fifteen independent innocuous ways to edit the memo - thesaurus some words, add or remove commas, etc. - and then send a unique permutation to each employee.
If they embed the same code number with two or three different sets of ten to fifteen modifications they can detect, if not work around, collaboration.
Now they'd have to be pretty paranoid to do this as a matter of course, but after a few leaks they might get wise and try something.
ART produce RenderDrive, a network rendering appliance, and PCI render processing card to run in your MAX/Maya workstation. Their whole business is render-optimized processing.
Anyone have any experience with these? Is this middleground this thread's looking for - high quality, quick and (relatively) cheap - between render farms and GPUs? Are GPUs a better price/utility tradeoff?
(I attended a lecture by the founder of ART a few years ago - their technology looked staggeringly impressive back then.)
Doesn't scream "nerd" - no URL, no explicit 'BSD'.
This, to me, is a good thing - I'll probably buy a T-shirt. If they were my thing, I might buy a cap. But it's an unknown logo with limited 'cool' so I wouldn't buy smarter or more clothes in the range.
On the other hand, maybe they've also missed the BSD evangelist market - the niche mark-me-as-a-geek and proud of it market. It's hard to see who they're pitching for, and I can only imagine they'll lose money - which is sad if you think BSD is worth supporting.
They could always try a serious promote-the-logo campaign, but it would always have nerd undercurrents and not be taken seriously.
I'm still waiting for them to get the variable declarations in for-loops right.
If you compile with the 'disable extensions' flag,/Za, then they already do.
Even with extensions enabled, VC++ 7 will warn when there's a conflict between extended and correct behaviours:
forvar.cpp(4) : warning C4288: nonstandard extension used : 'i' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope
If they will, as the article hints, submit these to the W3C then bear in mind that Microsoft helped draw up the W3C's Patent Policy which requires a 'Reasonable and Non-Discriminatory' license.
If you're saying that Microsoft's implementation of the standard protocols will probably be better and more useful than anyone else's, then I don't see what the problem is - that's just normal competition. Chances are Apache will embrace any new XML-based internet standard anyway, so any MS implemention won't be competition-free and it's up to interested people to make sure Apache's implementation (or whoever's) can hold its own.
If you're saying that Microsoft will extend the protocol for their own good then I don't think they will - they're not adverse to pushing a technology simply for the greater good.
Take SOAP, for example: a distributed RPC mechansim without any platform ties. Microsoft didn't need a new distributed RPC mechanism for Windows only environments but they still contributed a lot to the SOAP standard and development. It wasn't purely developed by Microsoft. It has been proposed to (adopted by?) the W3C. It has its drawbacks, but as a text-based XML protocol it's a pretty good standard.
But what good is a standard if no-one implements or uses it? Worse still, what good is one standard if everyone else only implements a different one? Microsoft can use their market presence to ensure that all Windows systems are bundled with a free, easy-to-develop-for and standards compliant SOAP implementation.
Microsoft have made no move to crush Developmentor SOAP (but then Developmentor were in on the standardisation and Don Box give Keynote addresses for MS), nor have they attempted to crush Apache SOAP or any of the dozens other SOAP implementations out there. Yes, perhaps they are trying to shut out other XML-RPC mechanisms in favour of SOAP, but in this case I think that they are attempting to unify the world simply for the greater good.
But it's not worth it if i can't re-compile my kernel and learn from looking through the source.
If you did recompile your kernel, how would you boot into it? You can't just burn a new CD yourself because of the PS2 copy protection system. If they haven't designed their bootloader to let you do this then you'd have to resort to/proc/kmem tricks.
My understanding is that they only have to offer the source to anyone they give a binary to, i.e. anyone who buys a PS2 Linux kit. However, they then can't stop someone who did buy a kit posting the source on the web.
MIPS asm is hardly more obfuscated than C (I'll admit that's a slight exaggeration). For example, to load an integer into a register you just li register value
But you have to worry about manual register allocation and a hard-coded register allocation can stifle reuse and maintainability. Tuning your C compiler is far better in the long term.
why would Sony make gcc their standard compiler on the $10000 PS2 SDK's if it was entirely useless
Because it does a reasonably good job and because it's free. There does appear to be a good market in third party PS2 compilers though (Codeplay et al.)
Slashdot Mirror
However, the original writer is missing a *very* important point. CVS branches are not simple and cheap. To branch, every ,v file in the repository must be entirely rewritten to insert a couple tags at the front of the file.
Yeah, in that case I meant 'simple and cheap' in terms of storage overhead and not operational cost. Sorry. (Not sure - CVS might also require a full-repository lock to do that which is an even bigger issue than the read-write in a busy system.)
My question (as I've elaborated elsewhere) was about branching a subdirectory a few levels deep for my own development so I wasn't considering the cost of the branch operation.
I've sat down with the design doc again: my main worry is exactly section 8.1.3 ('User Interface for Branches and Tags' in 'Future'): my concern was that I couldn't make an experimental branch in the company-wide repository without it showing up at top-level and sparking 'what's that doing there?' witch-hunts.
,v files in the CVS case. However, I'm sure this could be accomplished in SVN by some sort of repository merge module in your layered architecture.
,v files if I get myself in a particular mess - but, had I been using subversion instead, I probably wouldn't have had to.
Greg points out that branches can live under a '/branch/' root - which goes some way to addressing this if everyone's working against trunk, but if we're working on a branch as a matter of course (e.g. stabilising a release) then it doesn't really help.
My secondary concern is that I can't make an independent branch a few levels down, e.g.:
* projectA
* subprojectA1
* subprojectA2
* subprojectA3
* projectB
* projectC
Say I wanted to work on a branch subprojectA1 but track trunk changes to subprojectsA2 and 3. This is trivial in CVS - tag and update subprojectA1 to the new tag, and then cvs update at top level works as I'd like. This may be possible by munging the SVN state directories but I don't see an obvious way of doing this automatically from the design doc.
A practical example of this might be the sources.redhat.com 'uberaum' repository which is combined from the GCC and binutils repositories; I don't know if it's as simple as symlinking the directories of
Still not sold on the revision numbering - automated whole-repository state is useful but bumping revision numbers and $Revision$ tags when the individual file hasn't changed will confuse non-savvy diff tools and, unless you preserve the date stamp, trigger unnecessary rebuilds (but then if the $Revision$ tag is in a string to compile-in then you *want* to trigger a rebuild - how to distinguish the two cases?). I think the dot-notation would have been useful to keep - it's obvious that 6.1 and 7.1 were branched from different parents whereas I'd have to do some svn operation to know that versions 35 and 38 were.
I might also miss the option of hand-hacking the
One need only look at some of the problems large projects like GCC have with it to realize that some alternative is needed.
GCC's only problem, AFAICS, is the underlying RCS storage model: it's locking requirements, no central revision number store (for cheap no-change updates) and the patch-back-and-forwards operational cost of updating a branch.
I used Sourcesafe before I used CVS. One of the things that first impressed me with CVS was the branch model c.f. Sourcesafe's - specifically cheap, relatively unobtrusive/invisible branches: if I wanted to take one of our codebases and make my own experimental branch to hack around on then I can and it won't get questioned too much. I'm disappointed that subversion has adopted the Sourcesafe model but I confess I haven't studied the design docs to find out why. (I'm put off experimental-hack branches in the Sourcesafe model because they pollute the GUI.)
Was it truly anonymous? Given that this sort of thing is bound to get leaked, would they have embedded traitor identification in the memo? c.f. Yuval's "How to swindle Rabin", all they have to do is pick ten to fifteen independent innocuous ways to edit the memo - thesaurus some words, add or remove commas, etc. - and then send a unique permutation to each employee.
If they embed the same code number with two or three different sets of ten to fifteen modifications they can detect, if not work around, collaboration.
Now they'd have to be pretty paranoid to do this as a matter of course, but after a few leaks they might get wise and try something.
ART produce RenderDrive, a network rendering appliance, and PCI render processing card to run in your MAX/Maya workstation. Their whole business is render-optimized processing.
Anyone have any experience with these? Is this middleground this thread's looking for - high quality, quick and (relatively) cheap - between render farms and GPUs? Are GPUs a better price/utility tradeoff?
(I attended a lecture by the founder of ART a few years ago - their technology looked staggeringly impressive back then.)
Doesn't scream "nerd" - no URL, no explicit 'BSD'.
This, to me, is a good thing - I'll probably buy a T-shirt. If they were my thing, I might buy a cap. But it's an unknown logo with limited 'cool' so I wouldn't buy smarter or more clothes in the range.
On the other hand, maybe they've also missed the BSD evangelist market - the niche mark-me-as-a-geek and proud of it market. It's hard to see who they're pitching for, and I can only imagine they'll lose money - which is sad if you think BSD is worth supporting.
They could always try a serious promote-the-logo campaign, but it would always have nerd undercurrents and not be taken seriously.
I'm still waiting for them to get the variable declarations in for-loops right.
/Za, then they already do.
If you compile with the 'disable extensions' flag,
Even with extensions enabled, VC++ 7 will warn when there's a conflict between extended and correct behaviours:
forvar.cpp(4) : warning C4288: nonstandard extension used : 'i' : loop control variable declared in the for-loop is used outside the for-loop scope; it conflicts with the declaration in the outer scope
If they will, as the article hints, submit these to the W3C then bear in mind that Microsoft helped draw up the W3C's Patent Policy which requires a 'Reasonable and Non-Discriminatory' license.
I don't see what your point is.
If you're saying that Microsoft's implementation of the standard protocols will probably be better and more useful than anyone else's, then I don't see what the problem is - that's just normal competition. Chances are Apache will embrace any new XML-based internet standard anyway, so any MS implemention won't be competition-free and it's up to interested people to make sure Apache's implementation (or whoever's) can hold its own.
If you're saying that Microsoft will extend the protocol for their own good then I don't think they will - they're not adverse to pushing a technology simply for the greater good.
Take SOAP, for example: a distributed RPC mechansim without any platform ties. Microsoft didn't need a new distributed RPC mechanism for Windows only environments but they still contributed a lot to the SOAP standard and development. It wasn't purely developed by Microsoft. It has been proposed to (adopted by?) the W3C. It has its drawbacks, but as a text-based XML protocol it's a pretty good standard.
But what good is a standard if no-one implements or uses it? Worse still, what good is one standard if everyone else only implements a different one? Microsoft can use their market presence to ensure that all Windows systems are bundled with a free, easy-to-develop-for and standards compliant SOAP implementation.
Microsoft have made no move to crush Developmentor SOAP (but then Developmentor were in on the standardisation and Don Box give Keynote addresses for MS), nor have they attempted to crush Apache SOAP or any of the dozens other SOAP implementations out there. Yes, perhaps they are trying to shut out other XML-RPC mechanisms in favour of SOAP, but in this case I think that they are attempting to unify the world simply for the greater good.
But it's not worth it if i can't re-compile my kernel and learn from looking through the source.
/proc/kmem tricks.
If you did recompile your kernel, how would you boot into it? You can't just burn a new CD yourself because of the PS2 copy protection system. If they haven't designed their bootloader to let you do this then you'd have to resort to
My understanding is that they only have to offer the source to anyone they give a binary to, i.e. anyone who buys a PS2 Linux kit. However, they then can't stop someone who did buy a kit posting the source on the web.
MIPS asm is hardly more obfuscated than C (I'll admit that's a slight exaggeration). For example, to load an integer into a register you just li register value
But you have to worry about manual register allocation and a hard-coded register allocation can stifle reuse and maintainability. Tuning your C compiler is far better in the long term.
why would Sony make gcc their standard compiler on the $10000 PS2 SDK's if it was entirely useless
Because it does a reasonably good job and because it's free. There does appear to be a good market in third party PS2 compilers though (Codeplay et al.)