Source Control
-
Zdeslav Vojkovic wrote:
subversion documentation
We are using another source control tool in our company, and I think that the way subversion is optimally used differs from "standard" source control tools. Thanks for the link.
Company policy : no access to the internet but CP ~RaGE()
-
Marc Clifton wrote:
On the other hand, Subversion is becoming the standard, if it isn't already.
For small to medium-size teams, yes. Big ones need heavy systems like ClearCase or Perforce.
Nemanja Trifunovic wrote:
Big ones need heavy systems like ClearCase or Perforce.
CC is the default at my company, I'm curious what you see as being its primary advantages as it scales to larger projects? I mainly see the ways it sucks: no way to change branchs via gui (a textbox to edit a config file doesn't count), and no simple way to view an old version of a file (the send to context menu saves as a guid, and checking out an old version just to view it's unnatural).
-- CleaKO The sad part about this instance is that none of the users ever said anything [about the problem]. Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
-
Nemanja Trifunovic wrote:
Big ones need heavy systems like ClearCase or Perforce.
CC is the default at my company, I'm curious what you see as being its primary advantages as it scales to larger projects? I mainly see the ways it sucks: no way to change branchs via gui (a textbox to edit a config file doesn't count), and no simple way to view an old version of a file (the send to context menu saves as a guid, and checking out an old version just to view it's unnatural).
-- CleaKO The sad part about this instance is that none of the users ever said anything [about the problem]. Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
Don't get me wrong, I am not a fan of CC - in fact I really dislike it (at least the GUI part). However, it handles a big number of users much better than SVN - just compare the merging capabilities of the two systems; in fact, SVN doesn't even have real merging, it is more like Unix "patch". Our team is pretty small (5 developers) and we already run into problems with merging (rarely, though). Just can't imagine a big software company with 1000+ developers wrking on the same project and using SVN.
-
Don't get me wrong, I am not a fan of CC - in fact I really dislike it (at least the GUI part). However, it handles a big number of users much better than SVN - just compare the merging capabilities of the two systems; in fact, SVN doesn't even have real merging, it is more like Unix "patch". Our team is pretty small (5 developers) and we already run into problems with merging (rarely, though). Just can't imagine a big software company with 1000+ developers wrking on the same project and using SVN.
That's certainly a cheerful thought. I'm a solo dev on my application so it's almost never an issue for me. OTOH the one time I had major merge issues the official IBM help solution was instructions on how to replace their merge tool with a 3rd party one (KDiff). Aside from looking uglier than sin (a common failing with OSS apps) it stomped CC's xml merge tool in every way. The CC tool's problems were two fold. First it was overly anal about what it considered a separate change (allegedly the level it focused at could be an issue with really fancy XSL transforms) and merging large chunks of removed data back in resulted in ~4k unique merge items. It's default resolutions weren't correct (the version with the removed data I wanted to move it was older than the current version so it defaulted to NO at each merge), and there was no way to navigate between resolved merge points except via VCR buttons. There was a 'merge as text' option that could be made to use with a mess of hoops, but badly phrased loss of work warnings made it very easy to overwrite your text merge with the screwed up XML merge tool results.
-- CleaKO The sad part about this instance is that none of the users ever said anything [about the problem]. Pete O`Hanlon Doesn't that just tell you everything you need to know about users?
-
Marc Clifton wrote:
On the other hand, Subversion is becoming the standard, if it isn't already.
For small to medium-size teams, yes. Big ones need heavy systems like ClearCase or Perforce.
Nemanja Trifunovic wrote:
Big ones need heavy systems like ClearCase or Perforce.
Steve Maier
-
Anyone care to explain why my post got voted down ?
Company policy : no access to the internet but CP ~RaGE()
Rage wrote:
Anyone care to explain why my post got voted down ?
Free the sources!! break down the chains of control!! rise up!! Lets hear it for free sources!! ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Zdeslav Vojkovic wrote:
subversion documentation
We are using another source control tool in our company, and I think that the way subversion is optimally used differs from "standard" source control tools. Thanks for the link.
Company policy : no access to the internet but CP ~RaGE()
Rage wrote:
and I think that the way subversion is optimally used differs from "standard" source control tools.
yes, and no. Yes in that the terms are very different, and the storage method very different. Tri-merge is different than bi-merge, and negative differencing, at first, is odd. But in the end these are implimentation strategies. Subversion is very different internally, this is very true. There are some distinct advantages of negative differencing in that the most recent (head) object is kept whole and the differences to go BACK are kept in source control. As opposed to keeping the original sources, and the positive differences to get to the current. The assumption is the path of one or more steps back will be used more often than starting back from square one, which is a pretty good assumption. Other issues of atomic directories and stuff make the terms confusing, but in the end it can still be implimented via check-out, update, check-in. Team multiple-changes in the tri-merge can give you some new options that come as a surprise, but they are easily adapted to. many clients are in working states to provide direct implimentation to existing client interfaces, such as Visual Studio .Net[^] and many others.[^]
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Rage wrote:
Anyone care to explain why my post got voted down ?
Free the sources!! break down the chains of control!! rise up!! Lets hear it for free sources!! ;P
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
-
Zdeslav Vojkovic wrote:
subversion documentation
We are using another source control tool in our company, and I think that the way subversion is optimally used differs from "standard" source control tools. Thanks for the link.
Company policy : no access to the internet but CP ~RaGE()
Rage wrote:
I think that the way subversion is optimally used differs from "standard" source control tools
Which is a bit of a shame... I've taken to using the SVN model even when i'm using a system other than SVN - it's just sooo much more productive. I look back on the days i'd spend explicitly involving source control in every change i made (no matter how transient) as a tremendous waste of time.
----
It appears that everybody is under the impression that I approve of the documentation. You probably also blame Ken Burns for supporting slavery.
--Raymond Chen on MSDN