I really disagree. Locking is a half-ass solution and almost invites the deadlock situation.
There is no way to avoid the merge if you really want to have an open-minded but efficient parallel development environment. The scaling up is done by organising "delivery streams" and merging them into the final product. Of course you try to avoid overlap by good software design and by dispatching tasks properly, but you don't outlaw overlap via locking.
The really unfortunate side of current software development environments is that they produce more and more binary data files that are not mergeable and essentially punt on all the hard problems...
The problem with going behind the scene is that your changes will affect everybody, instantly.
The point of having versioned directories is that you can go about your reorganization at a leasurely pace, keeping in synch with all the other people, test it and then commit it and have your other developers absorb the change at their leasurely pace.
The only system I know of that can do this is ClearCase. Yes, it is a complex system that requires a very competent admin (like me), but then, I can do things with ClearCase that would be unthinkable in any other system
The single best feature of ClearCase is correct support for renames and relocations. No other system allows one person to reorganize a whole source tree and still keep the history of every element intact.
The value of this is vastly underestimated. Just imagine not having to spend so much time figuring out the initial layout of the tree, since you can modify it as the project evolves. Just think of all those crappy class hierarchies that only exist because reorganizing the source tree is such a hassle, and just look at the contortions tools like VC++ go through to enable developers to reorganize their prohects without moving the files - all because renames are tough to do in any system but ClearCase.
As for all the other perceived and real flaws, they all can be dealt with by a competent ClearCase guru (like me).
... that doesn't punt on managing multiple versions of the same "thing" and multiple parallel instances of the same thing running at the same time, with all the runtime configuration problems that go with it.
For example: it is impossible to create a package of, say, a sophisticated perl module without having to effectively include a whole perl distribution with it. Why? Because it is impossible to have two different versions of the same module available at the same time, at least not without serious trickery
These are the really hard problems, and as long as they are being ignored, this new packager is just so much wasted effort.
The main reason for moving to exchange is not just to replace one email system with another. It is to be able to take advantage of all the other goodies, of which multimedia, parallel editing and merging of documents are only the tip of the iceberg.
Exchange is really an ERP solution in disguise, and it's being agressively expanded in that direction. It is extremely easy for people to set up various forms and business processes (purchase orders, expense reports and HR forms etc), and is therefore very attractive for exactly those kinds of people that don't read slashdot:).
Of course exchange has a huge set of drawbacks, but they are in many ways comparable to the drawbacks of a sendmail based system:
1) It requires experts to set up securely and
properly (it's not impossible, though).
2) It suffers from the usual 4gl trap, that is
everything that is slightly outside of the
scope of the default objects suddenly becomes
very very hard to implement (similarly hard
to writing perl XS modules, for example).
3) Parallel development and good change control
is nearly impossible. This problem is similar
to the problem of versioning and merging
database schemas, as every change you do is
"live".
Lottery is actually an insurance policy...
on
Deja For Sale
·
· Score: 2
It's an insurance policy against good luck.
Imagine you selected 6 lottery numbers, but didn't buy the ticket. Disaster strikes: your numbers come out. Too bad you're uninsured.
The problem with this method is that you lose the capability to merge changes made by another developer while you relocated it. All his changes end up in the Attic.
Slashdot Mirror
I really disagree. Locking is a half-ass solution and almost invites the deadlock situation.
There is no way to avoid the merge if you really want to have an open-minded but efficient parallel development environment. The scaling up is done by organising "delivery streams" and merging them into the final product. Of course you try to avoid overlap by good software design and by dispatching tasks properly, but you don't outlaw overlap via locking.
The really unfortunate side of current software development environments is that they produce more and more binary data files that are not mergeable and essentially punt on all the hard problems...
The problem with going behind the scene is that your changes will affect everybody, instantly.
The point of having versioned directories is that you can go about your reorganization at a leasurely pace, keeping in synch with all the other people, test it and then commit it and have your other developers absorb the change at their leasurely pace.
The only system I know of that can do this is ClearCase. Yes, it is a complex system that requires a very competent admin (like me), but then, I can do things with ClearCase that would be unthinkable in any other system
See http://www.miaow.com/clearcase/
The single best feature of ClearCase is correct support for renames and relocations. No other system allows one person to reorganize a whole source tree and still keep the history of every element intact.
The value of this is vastly underestimated. Just imagine not having to spend so much time figuring out the initial layout of the tree, since you can modify it as the project evolves. Just think of all those crappy class hierarchies that only exist because reorganizing the source tree is such a hassle, and just look at the contortions tools like VC++ go through to enable developers to reorganize their prohects without moving the files - all because renames are tough to do in any system but ClearCase.
As for all the other perceived and real flaws, they all can be dealt with by a competent ClearCase guru (like me).
... that doesn't punt on managing multiple versions of the same "thing" and multiple parallel instances of the same thing running at the same time, with all the runtime configuration problems that go with it.
For example: it is impossible to create a package of, say, a sophisticated perl module without having to effectively include a whole perl distribution with it. Why? Because it is impossible to have two different versions of the same module available at the same time, at least not without serious trickery
These are the really hard problems, and as long as they are being ignored, this new packager is just so much wasted effort.
The main reason for moving to exchange is not just to replace one email system with another. It is to be able to take advantage of all the other goodies, of which multimedia, parallel editing and merging of documents are only the tip of the iceberg.
:).
Exchange is really an ERP solution in disguise, and it's being agressively expanded in that direction. It is extremely easy for people to set up various forms and business processes (purchase orders, expense reports and HR forms etc), and is therefore very attractive for exactly those kinds of people that don't read slashdot
Of course exchange has a huge set of drawbacks, but they are in many ways comparable to the drawbacks of a sendmail based system:
1) It requires experts to set up securely and
properly (it's not impossible, though).
2) It suffers from the usual 4gl trap, that is
everything that is slightly outside of the
scope of the default objects suddenly becomes
very very hard to implement (similarly hard
to writing perl XS modules, for example).
3) Parallel development and good change control
is nearly impossible. This problem is similar
to the problem of versioning and merging
database schemas, as every change you do is
"live".
It's an insurance policy against good luck.
Imagine you selected 6 lottery numbers, but didn't buy the ticket. Disaster strikes: your numbers come out. Too bad you're uninsured.
One obvious solution to this mess is that a tax be levied on every computer, similar to the way a tax is levied on TVs in most european countries.
The funds collected will be redistributed to the IP owners proportionaly according to download stats.
The problem with this method is that you lose the capability to merge changes made by another developer while you relocated it. All his changes end up in the Attic.