Death to svn?

Discussions

News: Death to svn?

  1. Death to svn? (68 messages)

    The Mozmill open source project team recently posted a message to their user community titled "Death To SVN". It read like this: "I just realized that I forgot to re-address why we are moving off of SVN. While svn remains the most widely known and used source control system the coordination cost for the current developers to use it has gotten too high. The committers routinely step on each others changes and overwrite code unintentionally because SVN basically sucks at dealing with any changes in the same file and likes to just overwrite things without telling you. The frame of this discussion should be on balancing the needs of the current contributors with the needs of possible/new contributors in the future. I think svn still has a lot of merits on the side of attracting new people because of it's wide use but those merits are dwarfed by the coordination costs of the current contributors." What do TSS people think? -Frank Cohen http://www.pushtotest.com

    Threaded Messages (68)

  2. Re: Death to svn?[ Go to top ]

    "overwrite things without telling you." I have never ever seen svn do that, and the users claiming so must have misunderstood somethingf fundamental. That said, I find svn increasingly useless for distributed development. GIT and Mercurial is just sooo much nicer for large projects.
  3. Re: Death to svn?[ Go to top ]

    "overwrite things without telling you."

    I have never ever seen svn do that, and the users claiming so must have misunderstood somethingf fundamental.
    I too find this hard to believe. I have never experienced this and I know that I've often had to resolve merge conflicts. Could it be that they are using a tool like Tortoise that is causing these issues?
  4. Re: Death to svn?[ Go to top ]

    Could it be that they are using a tool like Tortoise that is causing these issues?
    I find that hard to believe. I use tortoise and have not experienced this.
  5. Re: Death to svn?[ Go to top ]

    I think it is meant that you cannot fix your changes before you update the working directory. So, you have made some changes and has a consistent and build-able working directory. Without making the private branch, you cannot fix this state before doing the update. When you update, you risk getting a mess in the WD, because your changes weren’t cleanly merged with changes made by others. Bad thing is that you cannot revert either, because you will lose all of your local work! In Mercurial, for example, you commit BEFORE you update. So, you fix your changes first (they are perfectly safe in the local repository). After that, you pull+update and merge your changes with changes of others (and you can revert anytime you want without losing anything, but the merge work).
  6. Git is the best scm now[ Go to top ]

    Git is the one best SCM now, with Mercurial being second, and more people are realizing this every day. Git is so much better in all ways except the GUI tooling which is coming along. SVN has only recently added merge tracking. The SVN version I'm forced to use doesn't have it, so I'm using git as a frontend to SVN and doing all the merges with it instead. With git you actually enjoy using your scm.
  7. Re: death to svn[ Go to top ]

    subversion on its own would not overwrite changes like that. Whenever this had happened on my projects, it was because a developer decided to clobber someone else's changes instead of taking time to properly merge. Developers wouldn't want to spend time properly merging usually because there was too much to merge. There was too much to merge because people weren't committing changes often enough (sitting on them for weeks). Finally, people weren't committing changes often enough because of the way the build/deployment process was structured.
  8. Re: death to svn[ Go to top ]

    subversion on its own would not overwrite changes like that. Whenever this had happened on my projects, it was because a developer decided to clobber someone else's changes instead of taking time to properly merge. Developers wouldn't want to spend time properly merging usually because there was too much to merge. There was too much to merge because people weren't committing changes often enough (sitting on them for weeks). Finally, people weren't committing changes often enough because of the way the build/deployment process was structured.
    Very true.
  9. Re: death to svn[ Go to top ]

    This is so very true
  10. This is from Mikeal, one of the commiters on the Windmill project: To clarify, this is how svn ends up overwriting changes without telling you. You have local changes in your editor that are not saved. You svn update and it changes all the local files, your editor then saves, overwriting the changes in the file. Because svn doesn't diff between changesets but instead only diffs between the local changes and the changes in the main repository the only integrity check it can do is to check that it's local version matches the main repo version, which it will even tho you overwrote that code. Then svn allows you to checkin just fine and overwrite the changes in the main repository. Because you can't checkin locally, it's common to keep lots of changes locally and even in your editor without checking them in or sometimes even saving them, so this is less of a problem in DCVS because it becomes routine to checkin often and even save+checkin before you pull down changesets. Also, if you do screw up like this, you can revert just that single block in hg and git. The cost of recovery is small from problems like this and merges are still smooth because the history of where all the changes came from can be preserved. -Mikeal http://www.getwindmill.com
  11. only diffs between the local changes and the changes in the main repository the only integrity check it can do is to check that it's local version matches the main repo version, which it will even tho you overwrote that code.
    Sorry, you lost me here. If you overwrote the code, why would it match what's in the main repository?
  12. That sounds like your editor is behaving badly, not svn. Your editor should detect changes on disk and let you load them, rather than just blindly overwriting them. What editor are you using?
  13. The only time I've had Subversion give me grief with "over-writing code" is when I was at a company foolish enough to use Eclipse as the client. Subversion may not be the holy grail, but it does *work*.
  14. This is from Mikeal, one of the commiters on the Windmill project:

    To clarify, this is how svn ends up overwriting changes without telling you.

    You have local changes in your editor that are not saved. You svn update and it changes all the local files, your editor then saves, overwriting the changes in the file.

    Because svn doesn't diff between changesets but instead only diffs between the local changes and the changes in the main repository the only integrity check it can do is to check that it's local version matches the main repo version, which it will even tho you overwrote that code. Then svn allows you to checkin just fine and overwrite the changes in the main repository.

    Because you can't checkin locally, it's common to keep lots of changes locally and even in your editor without checking them in or sometimes even saving them, so this is less of a problem in DCVS because it becomes routine to checkin often and even save+checkin before you pull down changesets. Also, if you do screw up like this, you can revert just that single block in hg and git.

    The cost of recovery is small from problems like this and merges are still smooth because the history of where all the changes came from can be preserved.

    -Mikeal

    http://www.getwindmill.com
    WOW! With that level of incompetence, remind me not to allow this guy anywhere near my repos.
  15. What you've described isn't a problem with Subversion. It's a problem with your editor. If the file has changed on disk after you started editing, and your editor doesn't inform you, then I think you need a new editor. :) Eclipse, Emacs, kwrite will all detect that condition and ask you how you want to handle it. In any case, it's risky to deliberately initiate an action (svn update) that will potentially change files that you haven't saved in your editor.
  16. Re: Death to svn[ Go to top ]

    I have not seen SVN overwriting changes..But, it is definitely a hassle to coordinate when multiple developers are working concurrently on same piece of code..I guess there is a price to pay for adopting optimistic locking.. One thing that I would like SVN to do is to notify when there is concurrent development..
  17. Agree[ Go to top ]

    Yes agree, saying that SVN will die is frivolous at best, saying it overwrites things within a massive dev community is just nuts. Of course it doesn't, that's the whole point! I agree there are now better options than SVN, but SVN is so widely used across so many projects it will take an age to die. Lets face it, many people still start new projects on CVS because, all the devs know it and, their dev servers are configured for it. It's a huge investment to change and so that's why we like open source, no vendor breathing down our necks with our cheque book in their hands.
    I have never ever seen svn do that, and the users claiming so must have misunderstood somethingf fundamental ... GIT and Mercurial is just sooo much nicer for large projects.
  18. SVN overwriting code[ Go to top ]

    I have had this. I couldn't give you steps to reproduce the behaviour, but I have seen it. I work in a small development team. One of the things that I want to do is be able to share someone's changes without sharing it with everyone on an ad-hoc basis. This is something SVN can't help with: it requires a distributed system (git or mercurial). The number of times people break the build and screw things up for others is very high, causing many wasted, frustrating hours.
  19. Re: Death to svn?[ Go to top ]

    CVS => bad Perforce => bad If I don't use SVN, what should I use? Maybe Bazaar?
  20. Re: Death to svn?[ Go to top ]

    CVS => bad
    Perforce => bad
    OK, I can easily understand why someone might dislike CVS. Why is Perforce bad? Peace, Cameron Purdy | Oracle Coherence http://coherence.oracle.com/
  21. Re: Death to svn?[ Go to top ]

    CVS => bad
    Perforce => bad


    OK, I can easily understand why someone might dislike CVS.

    Why is Perforce bad?

    Peace,

    Cameron Purdy | Oracle Coherence
    http://coherence.oracle.com/
    I only used Perforce for a short period of time (I'm no expert), but here are few things about Perforce that I found very inconvenient and got in my way: 1. It's super-centralized: the Perforce server must know about all clients and their views. You cannot even move your local copy to a different directory without telling the server about it. 2. It sets all your local files to read-only mode. 3. You must lock-before-edit. 4. It's almost useless when you are off-line. Also, both Subversion and Perforce fall into the idea of representing branches in the same hierarchical namespace of your project files. Your project's file structure and branching are orthogonal things, but Perforce treats them as one single directory hierarchy.
  22. Re: Death to svn?[ Go to top ]

    I only used Perforce for a short period of time (I'm no expert) ..
    I use Perforce, Subversion and (unfortunately ;-) occasionally CVS. I'm not an expert with any of them. 1. It's super-centralized True. 2. It sets all your local files to read-only mode. True. 3. You must lock-before-edit. Not exactly: You have to "open" items (i.e. you or some tool has to tell Perforce that the file is potentially going to be edited), but it's not a lock (i.e. it doesn't block anyone else from doing the same). 4. It's almost useless when you are off-line. True until recently. There is now a full off-line mode, although I have not yet used it myself.
    Also, both Subversion and Perforce fall into the idea of representing branches in the same hierarchical namespace of your project files. Your project's file structure and branching are orthogonal things, but Perforce treats them as one single directory hierarchy.
    True, with Perforce it is important to think out the organization of the project and repository up front. My understanding is that Subversion was substantially based on Perforce, so the similarity is to be expected. At any rate, I find Perforce to be quite workable, which is unfortunately more than I could say for some (most? all?) of the other systems that I've been subjected to in the past ;-) Peace, Cameron Purdy | Oracle Coherence http://coherence.oracle.com/
  23. Re: Death to svn?[ Go to top ]

    I always found Perforce's merging facilities good as well. So long as your project setup suits the centralized model, I think Perforce is a great tool.
  24. Re: Death to svn?[ Go to top ]

    Perforce is a great tool, having used it for many years in multiple companies and am very happy with it, especially the branching and merging. I think the cost has kept it out of the mainstream, but personally I think the non-free tools like IntelliJ (let's not start a thread on that) and Perforce end up being cheaper in the long run.
  25. Subversion bugs...[ Go to top ]

    Subversion bugs are so annoying... I've had too much trouble with this seemingly simple bug: http://weblogs.java.net/blog/johnsmart/archive/2008/12/subversion_mave.html I think we need a project that aims to be a better SVN,the same way SVN was designed to be a better CVS ;-)
  26. It can improve, but it's fine[ Go to top ]

    ... because SVN basically sucks at dealing with any changes in the same file and likes to just overwrite things without telling you.
    I quite like the merging capabilities of SVN. I can't commit something if there are conflicts with a previous commit. Then I update which does a decent job at merging... Then I commit. It is not too bad. What I'd like SVN to have is grouping. If I commit many times for the same 'feature', I'd like to group all those commits in one logical unit. SVN has the huge advantage (for us) that it is widely known and a new developer does not need any training on it. It is open source too, so clients are free. Anyway, if you know of a better alternative, tell the folks at sourceforge, that's where we host :) Cheers, E. Conde Lead Developer jBilling.com - Open Source Billing
  27. You guys are jerks. SVN with all its faults would be a dream come true. I'm stuck with Clear Case here. Now my CM team will find this article and say, well someone doesn't like SVN so we'll continue to spend millions on Rational Products. So before you say death to SVN, think about us poor souls trying desperately to get to SVN. And because we're not able to dump ClearCase, don't even begin to think we have the capability to move to a distributed version control system
  28. You guys are jerks. SVN with all its faults would be a dream come true. I'm stuck with Clear Case here. Now my CM team will find this article and say, well someone doesn't like SVN so we'll continue to spend millions on Rational Products.
    Clearcase costs millions to purchase and maintain. SVN (software) is free. Therefore ClearCase is better. At least that's how most people think where I work.
  29. You guys are jerks. SVN with all its faults would be a dream come true. I'm stuck with Clear Case here. Now my CM team will find this article and say, well someone doesn't like SVN so we'll continue to spend millions on Rational Products.


    Clearcase costs millions to purchase and maintain. SVN (software) is free. Therefore ClearCase is better.

    At least that's how most people think where I work.
    Here, here... I compiled a catalog of ClearCase screenshots showcasing what can only be described as baffling UI design. One of my personal favorites was the "Find Files to Add To Version Control" dialog displayed by the ClearCase Eclipse plugin. You can't resize the small dialog window, so you have to scroll horizontally for each file that you want to identify as worthy of being committed or not. When dealing with a large number of new files with long package names this is a real pain. Also, what happens if you have tons of "generated" files in your workspace that you know you don't want to commit, like unit test reports. The designer of this dialog decided to include a "check all" button (all the files are already checked by default) but no "uncheck all" button, so now you have to scroll both horizontally and vertically for each file (possibly hundreds) and uncheck only the ones you don't want to commit! Having worked a lot with SVN before using ClearCase, I found the culture shock of moving from optimistic to pessimistic locking hard to get used to. My CPU was often pinned at 100% performing I/O to make hundreds of classes writable so I could do some JPA reverse engineering. Checking out code sometimes took hours to complete! Compare that with SVN where you can fire up your IDE and begin working right away without having to ask for permission to modify your source code! Maybe this behavior is by design, because the confounding three-way merge dialog in ClearCase is so hard to understand that it's probably best to avoid conflicts in the first place! :-)
  30. You guys are jerks. SVN with all its faults would be a dream come true. I'm stuck with Clear Case here. Now my CM team will find this article and say, well someone doesn't like SVN so we'll continue to spend millions on Rational Products.

    So before you say death to SVN, think about us poor souls trying desperately to get to SVN. And because we're not able to dump ClearCase, don't even begin to think we have the capability to move to a distributed version control system
    I'll second and third that feeling. I will gladly use SVN over ClearCase every day of the week and 3 times on sunday. I personally find SVN commit emails a big benefit, but it does rely on developers being mindful and considerate. If I see someone committing changes to the same file, I make sure I understand the changes and merge them locally if it's critical. If I fail to do that and then end up with merge hell, that's my own fault. Blaming SVN for my own laziness doesn't make a difference. What bothers me is when a product fights the developer every step of the way like clearcase. Even when developer are diligent, committing changes remotely with clearcase is often painful and sometimes impossible. At a previous job, I had trouble checking in 2 files with a half dozen lines of changes. It took 30 minutes before CC told me if failed. Even if I used Clearcase remote client, a checkin would still take several minutes over high speed internet. In contrast, with SVN I don't have any of those problems. peter
  31. I wish and pray for death of clear case...
  32. I wish and pray for death of clear case...
    I worked in the past with clear case. Just one project. It was enough; but I liked the merging ... :-)
  33. Clearcase = Spawn of Satan[ Go to top ]

    I personally believe that Clearcase is the devil.
  34. I personally find SVN commit emails a big benefit, but it does rely on developers being mindful and considerate. If I see someone committing changes to the same file, I make sure I understand the changes and merge them locally if it's critical. If I fail to do that and then end up with merge hell, that's my own fault. Blaming SVN for my own laziness doesn't make a difference.
    True. In my particular case, I *hate* Eclipse for its "Override and commit" feature.
  35. Even when developer are diligent, committing changes remotely with clearcase is often painful and sometimes impossible. At a previous job, I had trouble checking in 2 files with a half dozen lines of changes. It took 30 minutes before CC told me if failed. Even if I used Clearcase remote client, a checkin would still take several minutes over high speed internet.

    In contrast, with SVN I don't have any of those problems.
    IBM still charging for ClearCase despite its horrific behavior over anything but the highest speed LAN, the lack of any redress from IBM to these issues, and the presence of free alternatives combines to form a great example of milking a stubborn, entrenched market. By all rights no one should be using ClearCase today, but many are all but permanently wed to it. IBM knows this, takes their money and does nothing to improve ClearCase.
  36. You guys are jerks. SVN with all its faults would be a dream come true. I'm stuck with Clear Case here. Now my CM team will find this article and say, well someone doesn't like SVN so we'll continue to spend millions on Rational Products.
    Poor guy. You CMs will definitely go to hell after death for crimes against humanity. :) SVN is nice... until you try Mercurial.
  37. Only ClearCase can change DER-encoded certificate into a PEM-encoded one :) And once it decided to delete some lines from one javascript file - maybe it cares about my alertness? - nothing keeps a developer more concentrate than finding what's wrong with javascript... But seriously - I've decided to move some projects in my company from CC to SVN (even the project, that was used to evaluate ClearCase) - without approval of management. Now there are only few projects left rotting in ClearCase, but I hope CC's days are numbered. SVN works great - especially when there must be remote, synchronized repositories at client's machines (accessed by 33.6 kbps modem) to build applications from sources. Try to do that with CC...
  38. I consider myself as a "expert" of configuration managment (maybe I should not !?) And within my SCM life; I really consider ClearCase as the better SCM tool, really.
  39. CA Harvest SCM[ Go to top ]

    What do people think about CA's SCM called Harvest? Cheers, Bruno
  40. Re: CA Harvest SCM[ Go to top ]

    What do people think about CA's SCM called Harvest?
    Avoid anything owned by CA.
  41. In that the blues is a foundational music style, has been copied and reshaped into every modern musical style, and was created by a bunch of crusty old guys with crooked fingers. The elegance of clearcase is the "view" and the simple configuration file to define that view. Clearcase has the most elegant model and most solid architecture - defining it's only filesystem type - brilliant! Way ahead of their time. Now everyone wants a journaling filesystem. I love clearcase, but only because I've used it in the context it was designed for, which is a high-speed LAN. If you want a distributed repo, then you have to use multi-site. If you want a disconnected repo, then you have to use a snapshot view or remote client. Lack of decent dynamic view clients is the killer in my opinion. I've used many different SCM/versioning tools from SCCS (most of you have probably never even heard of it) to git, free and commercial. That said, I don't think anyone should pay for software, and the only thing I hate more than microsoft is IBM, so I would now avoid it at all costs (or no costs). Lately, I have to say, git, though my experience so far is limited, looks like the most well thought out tool. I would just be concerned about adoption by people of lesser skill and/or experience, but that just means it's on someone to make it easy for them.
  42. PVCS[ Go to top ]

    You should all think yourselves luck as the blue chip company I work for use the worst source control software. PVCS (RIP) I yearn for CVS, SVN or even clearcase ...
  43. Roger that.[ Go to top ]

    You should all think yourselves luck as the blue chip company I work for use the worst source control software.

    PVCS (RIP)

    I yearn for CVS, SVN or even clearcase ...
    We are lumbered with dimensions cm out of the same stable. If it was free nobody would download it, but marketing and glossy brochures work wonders.
  44. Whilst those who complain about ClearCase's performance probably have a point, most of the people who are really angry at it never got properly trained in its use. To use an an analogy... most people could figure out how to use a drill on their own and do a pretty decent job with it. But give the same people a jackhammer (pneumatic drill) and they will probably make a hell of a mess. If you only need a drill - great! Use a drill. If you need a jackhammer learn how to use it before you complain about the mess. And to be fair - it isn't the users of ClearCase who are at fault here - it is the people buying it and managing the users. They need to spend some money on training.
  45. Whilst those who complain about ClearCase's performance probably have a point, most of the people who are really angry at it never got properly trained in its use.

    To use an an analogy... most people could figure out how to use a drill on their own and do a pretty decent job with it. But give the same people a jackhammer (pneumatic drill) and they will probably make a hell of a mess.

    If you only need a drill - great! Use a drill. If you need a jackhammer learn how to use it before you complain about the mess.

    And to be fair - it isn't the users of ClearCase who are at fault here - it is the people buying it and managing the users. They need to spend some money on training.
    We had dedicated people managing clear case and it never really worked. We couldn't even get a local repository. That might have been because the CC administration was outsourced but at the upshot was that it took hours for my changes to be visible to others and the whole thing fell down on a nearly daily basis. Was there some other way I should have checked in my code? How complicated does it need to be?
  46. Whilst those who complain about ClearCase's performance probably have a point, most of the people who are really angry at it never got properly trained in its use.

    To use an an analogy... most people could figure out how to use a drill on their own and do a pretty decent job with it. But give the same people a jackhammer (pneumatic drill) and they will probably make a hell of a mess.

    If you only need a drill - great! Use a drill. If you need a jackhammer learn how to use it before you complain about the mess.

    And to be fair - it isn't the users of ClearCase who are at fault here - it is the people buying it and managing the users. They need to spend some money on training.
    The issue and flaw with CC is the design is too chatty and rather inefficient. Back when I worked at IBM, CC worked fine if the server had a dedicated OC connection. I've seen companies try to make due with a T1 or a shared T3 line. The thing is, if CC had a better design and implementation, it wouldn't require a ton of bandwidth to function efficiently. If you're on a LAN and never have to do remote check-in, CC is almost bearable. I'm sure there are those who think CC is great, but I've yet to meet one face to face.
  47. Whilst those who complain about ClearCase's performance probably have a point, most of the people who are really angry at it never got properly trained in its use.

    To use an an analogy... most people could figure out how to use a drill on their own and do a pretty decent job with it. But give the same people a jackhammer (pneumatic drill) and they will probably make a hell of a mess.

    If you only need a drill - great! Use a drill. If you need a jackhammer learn how to use it before you complain about the mess.

    And to be fair - it isn't the users of ClearCase who are at fault here - it is the people buying it and managing the users. They need to spend some money on training.
    Amazing. Why would I need training to use a version control system? That's just a really silly argument to say clear case sucks because you haven't been trained. The counter argument is quite easily, why do you need to be trained? Also, the fact I can't just fire up an instance at home and dig in makes the learning curve that much less tolerable.
  48. Training; ClearCase vs. SVN[ Go to top ]

    Users of version control systems do require training even if it is self-study or informal training provided by more experienced peers. I got multiple projects migrated to SVN from CC recently and unexpected consequence was that now I tend to be more aggressive in source code refactoring. CC would slow you down because you need to wait while files are "checked out".
  49. I consider myself as a "expert" of configuration managment (maybe I should not !?) And within my SCM life; I really consider ClearCase as the better SCM tool, really.
    I would imagine as an "expert" you should be able to give a little bit of detail as to why. My personal experience with CC was extremely negative. I'd like to hear why you think it's good. We needed basically a full-time person to keep the thing running. Could it be that it wasn't set up right? In general I've never understood why Rational was successful and even less so why anyone would want to follow their process.
  50. Clear Case is clearly a basket case[ Go to top ]

    Erik, It may be that as an expert in configuration management you've figured out something that the rest of us haven't. As for this lowly developers with about 15 years of experience under my belt I can say without any hesitation that I've never been forced to use anything as bad as Clear Case, except for Visual SourceSafe which was a software atrocity beyond compare.
  51. You guys are jerks. SVN with all its faults would be a dream come true. I'm stuck with Clear Case here. Now my CM team will find this article and say, well someone doesn't like SVN so we'll continue to spend millions on Rational Products.
    Very true. That's exactly for the same silly reason that we are -and for three years already- the single pilot project in my company that uses SVN instead of CVS. We push hard for it but we can't make it being accepted because of the stupid ideas about SVN you can find on the Internet. Anyone who has seriously used both CVS and SVN knows which one is the best of the two: so far, I haven't managed to find any argument for CVS against SVN. So, please, stop the evangelism, because that's not what the community needs. The popular SCM are usually open-source so, if you don't like them, either improve them or start another project on your own and see how the community reacts. If it's adopted, it's not because of the evangelism, but because it provides better features.
  52. Thinking about all this buzz and the reactions it gets, I realize that SVN has won over the other SCM on a point at least: its fast adoption in the community of developers. It's fun to read the comments about it like "death to SVN" or "there are now better options than SVN, but SVN [...] will take an age to die", when you know its first official release was on the 29th of September 2004 only and, at that time, you could have read exactly the same comments about CVS. This means that, while still being in use in much more projects than SVN, CVS is not anymore the standard SCM tool. It has been completely replaced by SVN in the dev community now. So, said in another way, SVN has achieved its primary goal: being a better CVS. Now, maybe it's time to move to something else, but personally I'm still not convinced DSCM is much better. The chapter 3 (Development Methodologies) of this web page leaves me completly undecided: http://bazaar-vcs.org/BzrForCVSUsers It seems to me there is no good way to use a DSCM without moving the synchronization process from the tools to the people. If it's so, that's not optimal.
  53. Re: Death to svn?[ Go to top ]

    Absolutely. Centralized SCMs are yesterday. Mercurial or git are so much better that it's just impossible to start using SVN after several weeks with git. About the only valid use-case for SVN is work with unmergeable file formats (images, CAD drawings, etc.)
  54. Re: Death to svn?[ Go to top ]

    I'll echo most of the posts here... lack of decent merging is slowly killing Subversion. I don't know what SVN folks are thinking about to be honest. Regards, Nikita Ivanov. GridGain - Cloud Development Platform
  55. Re: Death to svn?[ Go to top ]

    I'll echo most of the posts here... lack of decent merging is slowly killing Subversion. I don't know what SVN folks are thinking about to be honest.

    Regards,
    Nikita Ivanov.
    GridGain - Cloud Development Platform
    my bias take is the multi-branch style of development causes most of the problem with merges. If everyone works on the same branch, merges are less of an issue. That's not to say SVN merge can't improve. It definitely could be better, but it's still worlds better than clear case merge. my bias 2 cents.
  56. Re: Death to svn?[ Go to top ]

    can you please change the title of the story. A dumb manager will read it and assume that svn is bad and so never move to it. i m stuck with CVS and others in my company are even worst - on clearcase. please dont put eye-candy, glorified headlines... unless TSS is now owned by TMZ ;)
  57. "can you please change the title of the story." That's my fault. The title from the original email just seemed to stand out to me as something funny. I'll keep in mind that manager's read TSS too. BTW, I had no idea at the level of angst being created by Clearcase. -Frank
  58. "can you please change the title of the story."

    That's my fault. The title from the original email just seemed to stand out to me as something funny. I'll keep in mind that manager's read TSS too.

    BTW, I had no idea at the level of angst being created by Clearcase.

    -Frank
    That's only scratching the surface. The things I've personally said of clearcase gets far worse. I would say the majority of the people who use CC hate it passionately. That's not a scientific measurement, just my own first hand experience at the last several jobs. peter
  59. Re: Death to svn?[ Go to top ]

    Nobody uses Bazaar? Patrick
  60. Re: Death to svn?[ Go to top ]

    Nobody uses Bazaar?

    Patrick
    I used Bazaar(-ng) before moving to GIT and I liked it a lot. Incredibly easy to use and stable. But ultimately, GIT better supports my style of patch workflow. While Subversion has its problems, I don't mind using it for small projects. The things I hate the most: 1) The god damned .svn directories that pollutes the WC (yes, I know the rationale, and it's idiotic.) 2) It's centralized 3) Branching and merging is just painful compared to GIT, etc. Good things about SVN: 1) Uh, it's slightly better than CVS 2) Excellent client tools 3) Despite misinformed articles like this one, the SVN serverside is extremely stable.
  61. Merge/Branches in Subversion[ Go to top ]

    If you are stuck with subversion and every merge feels like pain, I can recommend SVK it really makes merging easier. There is a lack of GUI tools though.
  62. Re: Death to svn?[ Go to top ]

    Nobody uses Bazaar?

    Patrick
    Not for in-house stuff, but I have used it for a project on launchpad.net. It seemed generally quite good - the option to move between centralised and distributed methods in particular was great. The one problem I hit a couple of times was compatibility between versions, obscure errors while trying to use older clients (released in stable Linux distro versions) and little/no backwards compatibility. This put me off supporting Bazaar across the various different development workstation setups we use. Dominic
  63. We're happily using Bazaar[ Go to top ]

    Nobody uses Bazaar?

    Patrick
    After being a long time advocate of Subversion since its inception I switched my current company to Bazaar back in March. Frustration over the difficulties of concurrent branch management--outlined at http://blogs.open.collab.net/svn/2008/07/subversion-merg.html--got the best of us. We chose Bazaar over Git and Mercurial. User friendliness and workflow flexibility were the primary drivers. Things like directory versioning, true rename support, shelve/unshelve, uncommit, and other niceties contributed to the decision. In my career I've used RCS, SCCS, VSS, CVS, Perforce, and Subversion extensively at one time or another. Bazaar has been the first VCS I can say has just gotten out of the way. Not that we don't have a wish list for Bazaar as well: - True copy support. - Interactive merging, which is coming in next release. - More mature tool support. Tools such as Subclipse, TortoiseSVN, ViewVC etc. are arguably way ahead of their Bazaar counterparts. Rightfully so since most have or have had contributor critical mass, commercial sponsorship and a huge head start. We're very much hoping time brings these things to projects like BzrEclipse and TortoiseBzr. Same goes for Bazaar integration with other tools such as Jira, etc. - The Bazaar SmartServer is quite minimalist. We're getting by fine for now as a small team, but I can see larger deployments left wanting in this area. Bazaar core has consistently been advancing at a very impressive rate, so we have high hopes for the future.
  64. Re: We're happily using Bazaar[ Go to top ]

    Frustration over the difficulties of concurrent branch management--outlined at http://blogs.open.collab.net/svn/2008/07/subversion-merg.html--got the best of us.
    ... that link was supposed to be: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html
  65. facts or flames?[ Go to top ]

    Has TSS really come down so low that we are posting and discussing just flames? Where are the facts? What happened, how did SVN overwrite each others changes? Not a single word about those facts. Guessing, flames, assumptions, speculations. I need to stop reading TSS.
  66. Is it possible...?[ Go to top ]

    Is it possible that developers are waiting for days or weeks to do a check-in - and then not spending the time to visually review the merge process? Is it possible that developers are not doing periodic check-ins throughout the day? Is it possible taht class files are so large that multiple developers frequently need to work in the same file? Is it possible that perhaps the code needs to be refactored?
  67. I've been using Bazaar for over a year now and I can't say there has been a day where I've felt like I've been fighting against it. It has always done things the way I would have expected. I do a lot of refactoring (in Java) which is one of the reasons I picked Bazaar over Mercurial (lots of renames at both file and directory level). Bazaar was a little slow when I first used it but performance has improved immensely since then. Every time I've gone near git I've hit issues (on Windows) but I must admit I have never looked at it in earnest, it may well be a better tool. The beauty of Bazaar (to me anyway) is that it is the closest to "lossless" in terms of revision control tools that I've used. It tracks everything that I'm interested in. It works in any way you please, centralised, distributed or some variation/combination thereof. It is a tool that allows you to work in the way that you want and does not dictate how it should be used. It can adapt to your development culture. Death to subversion in my books, it is a mildly better CVS. I don't really mind which distributed rcs takes over from subversion as the defacto standard, provided I don't have to use subversion again.
  68. SVN Rocks[ Go to top ]

    I am not a SVN expert. But in my experience with VSS, Clearcase, CVS and SVN. I find SVN much better than others (in the list). Any version control software requires some sort of commonsense to use and if developers do not exercise their commonsense while merging files, the problems are bound to happen.
  69. Different Weeds and Bugs[ Go to top ]

    I am not an expert in Change Management tools but I am responsible for replacing CMSynergy with ClearCase at my company. I did not select either tools, so have no love or hate for either one. We also have a fairly large TFS implementation and a couple of users on SVN. No tool is perfect... and the grass is never greener, just different weeds and bugs... Don't dig to deep, you know what is under there. ClearCase has lots of issues because of what it has carried with it since the beginning. It is has the best out of the box merge tool, and is the only thing that will work on Rational Models (another product we are married too.) Anyone can go and acquire all the open source tools and put them together, but in a large organization the management becomes strenuous at best, impossible at worst. I am no defender of Rational or IBM but it is what it is, and Total Cost of Ownership for disparate tools usually overrides what you pay in licensing fees, so pick your poison. Finally, IBM never really "abandons" anything however its direction going forward seems to be the Jazz platform (www.jazz.net) which is like having Jira, Subversion, etc. etc. all rolled into one. Cost wise I think they have a long way to go, but the tool suite is very nice and free for up to 3 users. My useless 2 cents.