AVS - An Open Source SCM

Discussions

News: AVS - An Open Source SCM

  1. AVS - An Open Source SCM (41 messages)

    When looking for free source management software around the world, there are not so many choices. Source version management, such as SVN, CVS and GIT, are all based on the same data model, update and commit - in other words late conflict discovery, and file locking does not appear to be all that great. Moreover, why would I need to get everyone's work to commit my own one, with the risk of getting a non working workspace? Configuration management software, as Synergy and ClearCase offer, try to propose another way of working, based on a file check-out concept, and a branching per file mechanism. This lets everyone see files in a working state before any work is done, allowing early conflict discovery, with still the parallel development available on every files. This is really another way of working, which unfortunately does not hold so much popularity among the developer community since developers need to plan and declare what they intend to do ahead of time. Although, and even if not everyone will agree, working with Synergy is not difficult, and saves a lot of time for developers. Those SCM software tools are widely used in the industry, but are quite expensive too, and well known for their setup complexity and time consuming management. The AVS project is an attempt to propose another simple yet efficient alternative, and this configuration management software appears to be one of the first open source release of the kind. This project actually embeds both a configuration management part and a bug tracking part. Having both managed in the same repository allows a fine grain release management feature, selecting change requests instead of development tasks as can be done within Synergy reconfigure folders. AVS bug tracking allows users to define their own change request life cycles, creating new states and transitions potentialy restricted to dedicated roles. Of course, AVS also contains an ACL management, with groups and rights, allowing developers, project leaders and other roles, so everyone can only access what they should. In addition, a script feature allows quality engineers to set up code quality checks upon task check-in and change request close events. Those scripts are launched by the server with impersonation ("run-as") feature to avoid damage caused by malicious scripts. Apart from this particular feature, AVS is a 100% Java project, distributed as a Tomcat web application, using PostgreSQL database through Hibernate, with a client deployed using JNLP. A lot remains to be done, such as IDE plugins, a public repository will soon be available, hosted on an AVS instance of course! AVS is available for free download and commercial use at http://www.qarks.com

    Threaded Messages (41)

  2. Having suffered through clearcase hell[ Go to top ]

    You've got to be kidding. Clearcase style SCM is horrible. The only times I've seen clearcase work well is when branching/merging isn't used. At the last place I worked at, there was a constant battle over branching or not. The overhead of branch/merge just isn't worth it. friends don't let friends branch/merge with clearcase.
  3. The only thing I find that has the worth in ClearCase is the dynamic viewing, which is bitchy thing for Continuous Integration
  4. Clearcase style SCM is horrible
    Clearcase is a leader (together with serena dimensions and MKS) in 2008 gartner's "Magic Quadrant for for Software Change and Configuration Management for Distributed Platforms"! Never used it (none of those) and I usually value your opinion but also gartner has its catches. What would you suggest instead of clearcase?
  5. Clearcase style SCM is horrible

    Clearcase is a leader (together with serena dimensions and MKS) in 2008 gartner's "Magic Quadrant for for Software Change and Configuration Management for Distributed
    Platforms"!
    Never used it (none of those) and I usually value your opinion but also gartner has its catches. What would you suggest instead of clearcase?
    Gartner is often full of BS. That whole magic quadrant stuff is mostly BS. subversion and cvs work just fine. I personally prefer to have commit emails with the diff. this way, I know what lines were changed. If I happen to be working with that same file, I know there's changes that may need to be merged. in the places where branch/merge approach was used, merges usually took 2-4 days per branch, so in a large project with 8 branches, the merge would take up to 2 months. my advice is ignore what rational says about best practices for branch/merge. After everyone is used to branch/merge with clearcase, it still takes 1-2 weeks to merge 8-12 branches assuming you merge every other week. the longer you go between merges the more painful merges become. my bias 2 cents. peter
  6. Are there any places to read about the deficiencies of ClearCase branch and merge or about what handles it better and how? Artem
  7. Are there any places to read about the deficiencies of ClearCase branch and merge or about what handles it better and how?

    Artem
    since you asked. Here are some well known weaknesses of clearcase. I. checkin/checkout over VPN with the thick client horrendously slow. Unless your company has a dedicated fiber optic connection, it's basically unusable. Don't even bother trying with a T1 or a T3. II. doing a branch/merge over VPN is likewise horrendous with the thick client. III. even with the remote client, checkin/checkout is awefully slow. It's usable if your company has a lot of bandwidth. Again, don't try it with a T1. At minimum a dedicated T3 if you plan to have developers work remotely or have several groups working on the project distributed across several physical locations. IV. the merge functionality for xml files suck horrendously. you have to merge as text to get it work correctly. V. merging with multiple branches is painful if the same file was changed in multiple branches. this is mainly due to the UI design and how they show the differences between previous version, current and local. VI. the auto-merge in clearcase often screws up a file, but it doesn't tell you. often it does a merge append and ends up duplicating a method. clearcase says it the file merged ok, but when you try to compile it, it blows up. many people see this problem with many branches. VII. make sure the line break setting in clearcase is set correctly, otherwise it will add extra line breaks on checkin/checkout. that's the short list, there's plenty of other "quirks" of clearcase that make it horrendous and terrible. peter
  8. Thanks Peter, To summarize your points - ClearCase is unusable over high latency connections (that is my observation as well) - ClearCase merge UI is far from intuitive (that is my observation as well) - ClearCase merge algorithms are not error proof (have not experienced that myself while working for several years on a reasonably big project) Luckily, network latency is not an issue for me. Can you recommend another tool that has better merge UI and algorithms? Artem
  9. Thanks Peter,

    To summarize your points
    - ClearCase is unusable over high latency connections (that is my observation as well)
    - ClearCase merge UI is far from intuitive (that is my observation as well)
    - ClearCase merge algorithms are not error proof (have not experienced that myself while working for several years on a reasonably big project)

    Luckily, network latency is not an issue for me.

    Can you recommend another tool that has better merge UI and algorithms?

    Artem
    honestly, I don't know of any SCM that provides good merge. I prefer to manually merge files. since I contribute to a few open source projects, my bias is towards svn and cvs. my own experience, for what it's worth. svn and cvs are easier to learn than clearcase. it takes far more discipline to use clearcase and requires much more training. peter
  10. I don't have a big experience with Team Concert SCM, but if you are looking for some of the good things of CC (if you can find them) I think is a good choice: powerful, lighter and faster than CC. For example, for me, the possibility of having a developer level remote repository is a very interesting feature. Cheers
  11. subversion and cvs work just fine. I personally prefer to have commit emails with the diff. this way, I know what lines were changed. If I happen to be working with that same file, I know there's changes that may need to be merged
    ...er, ok, but this is ok for small projects or very talented people. Also - clearcase and dimensions are not just SCM, they integrate bug and requirement tracking, baseline/changedoc/release/documentation management, etc, useful stuff when it comes to big projects' governance. Svn or cvs should be used together with - dunno - mantis or trac and a bunch of other things to be compared to clearcase or dimensions
  12. subversion and cvs work just fine. I personally prefer to have commit emails with the diff. this way, I know what lines were changed. If I happen to be working with that same file, I know there's changes that may need to be merged
    ...er, ok, but this is ok for small projects or very talented people. Also - clearcase and dimensions are not just SCM, they integrate bug and requirement tracking, baseline/changedoc/release/documentation management, etc, useful stuff when it comes to big projects' governance.

    Svn or cvs should be used together with - dunno - mantis or trac and a bunch of other things to be compared to clearcase or dimensions
    I don't believe that statement is true. There are large projects using SVN with Jira for bug tracking. in my mind, clearcase does nothing well and tries to do too much. SVN does a specific thing and jira does a specific thing. use them together and it compliments each other. Also, svn doesn't require very talented developers. clearcase tries to be smart and ends up being very stupid in the process. back when i worked for ibm, we were force fed clearcase. it's a good thing i didn't drink the clearcase koolaid. I would never recommend clearcase to anyone. peter
  13. Ok, I didn't mention jira which I agree is the best complement to svn (which is also my choice over all other options). I also agree Jira and subversion together address the most part of the governance issues you can find in a large team of not-too-smart guys - much better than all those overbloated packagese (I have experience with MS team system - which made me miss svn quite a lot). Put some continuous integration and quality assurance stuff (see Sonar from codehaus) in the mix and you will also have a lot of fancy reports and graphs to delight the management with ;)
  14. Clearcase style SCM is horrible

    Clearcase is a leader (together with serena dimensions and MKS) in 2008 gartner's "Magic Quadrant for for Software Change and Configuration Management for Distributed
    Platforms"!
    Never used it (none of those) and I usually value your opinion but also gartner has its catches. What would you suggest instead of clearcase?
    I have to agree with the others, ClearCase blows big-time. Where I worked we needed a special trained person to tickle the repository's balls on a daily basis just to keep it running. Has anyone ever gone back and looked at Gartner's track record? I mean look at all their recommendations and see how well they have done over the years? It seems to me they often give really terrible advice. Peter Lin is basically a super-genius. I'd trust him over Gartner any day.
  15. CC is not evil, merely uncaring[ Go to top ]

    I fear CC. It is the only SCM tool where you need to have a full time person nurturing it. And when things go wrong, they go so very, very wrong. The failure mode of most SCM tools: you can't check in or update. The failure mode of Cruise control: nobody in the team can do any work. Our escalation policy was "have a virgin sacrifice a goat". Why the virgin? So we had something else to sacrifice if the goat wasn't enough. SVN is an excellent tool for enterprise development as well as open source. It integrates with every IDE, with the CI tools, and loves laptops. Git is emerging as an alternative for open source development, again, very laptop friendly. Learn to use them before chasing the misguided dream that is ClearCase
  16. Clearcase had a few things good things going for it. a. It has merge tracking. Which is necessary when you have multiple long running branches that you need to repeatedly merge between often. Subversion failed miserably in this department. b. The Version tree was the best way ever to see how a change got propagated from branch to branch. This is also impossible without merge tracking. c. The merge tool was good, especially in light of what existed at the time. Because subversion lacked merge tracking it just couldn't do a good job because you have to redo all your past work every time you do a repeated merge. d. If you know how to work the config spec you can do very sophisticated branching and merging. On the other hand Clearcase was horrible in a few respects which now outweigh the benefits. a. It was painfully slow. You would wish that you had remembered to kick off a brand new checkout before lunch. You can get a nice display in your version tree, but it takes so long to pull one up that it slows your work down. Merges would take half an hour to set up before you were ready to start with the conflicts. b. It's very expensive. By the time you finally get approval to upgrade to the latest version open source SCMs are better. If you want to get a bigger faster machine to speed up your SCM and increase developer efficiency then you have to pay up, so you end up not getting one. c. It's complicated. It's a big project to set up. It requires maintenance. (Just a note: Subversion finally got merge tracking in version 1.5 and earlier versions could use something called svnmerge) Git however is the future. a. It's fast, fast, fast. This radically changes how you work because you start to use the SCM the way it is supposed to be used, to track your changes, to use branches to help you. A merge is done in nothing flat. b. It retains all the history in the repository so diffs are done in nothing flat. c. It is distributed, which means you can actually check in things to your local git repository to track which you may or may not want to check into the actual shared branch. You decide later, when you are ready to check in. This lets you check in just the proper changes at the proper time. Switching branches is immediate so you can switch to working on a new critical issue in the trunk with just a quick command on the command line. d. Merge tracking is implicit. You can move files around and git figures it out all by itself without you needing to tell it. Repeated merges are not a problem. Because of this you can branch and merge to your hearts content and it stays easy. Here is a nice list of use cases: http://www-cs-students.stanford.edu/~blynn/gitmagic/ What the author says about needing to lock files is silly. I used Clearcase that way for 7 years. Locking files is just a workaround for avoiding merges. If your SCM makes the merges easy then file locking just slows people down because they can't change the files they need to. Mercurial is about as feature complete as Git, but it's just slower and the slowness matters. Having a fast SCM changes the way you work.
  17. What the author says about needing to lock files is silly. I used Clearcase that way for 7 years. Locking files is just a workaround for avoiding merges. If your SCM makes the merges easy then file locking just slows people down because they can't change the files they need to
    Well, thanks for the "silly" stuff.. actually, I'm a bit surprised because we absolutely agree, locking is indeed a workaround, that I'd rather not use. Did I say something else? and merge is the right option for sure. Just the thing is that I prefer knowing about the merge to come before rather than after the work to be done, that's all folk!
  18. What the author says about needing to lock files is silly. I used Clearcase that way for 7 years. Locking files is just a workaround for avoiding merges. If your SCM makes the merges easy then file locking just slows people down because they can't change the files they need to


    Well, thanks for the "silly" stuff.. actually, I'm a bit surprised because we absolutely agree, locking is indeed a workaround, that I'd rather not use. Did I say something else? and merge is the right option for sure. Just the thing is that I prefer knowing about the merge to come before rather than after the work to be done, that's all folk!
    If your procedure is to get a commit email of the diff, you know exactly what was changed in the file. I don't care if someone is planning to work on the same file, if they never get around to it. It's the actual changes they make that has the potential of conflicts. The way I look at it is this. If I see the same file was touched, I do a merge and continue with my work. if the change has a conflict, I talk to the other developer immediately. I prefer the developers on a project act responsibly, than branch and deal with merge nightmare. peter
  19. I don't care if someone is planning to work on the same file, if they never get around to it. It's the actual changes they make that has the potential of conflicts.
    Right. The only time it makes sense to lock a file is you are going to make drastic changes which would make anyone else's concurrent changes obsolete.
  20. I don't care if someone is planning to work on the same file, if they never get around to it. It's the actual changes they make that has the potential of conflicts.


    Right. The only time it makes sense to lock a file is you are going to make drastic changes which would make anyone else's concurrent changes obsolete.
    In those cases, my preference is to know who is working on what. This way, we can communicate and keep each other informed. Perhaps both developers are trying to solve the same problem, so it makes sense to communicate first before conflicting changes collide. Locking the file prevents someone else from modifying it, but it doesn't make you more efficient. peter
  21. Clearcase style SCM is horrible

    Clearcase is a leader (together with serena dimensions and MKS) in 2008 gartner's "Magic Quadrant for for Software Change and Configuration Management for Distributed
    Platforms"!
    Never used it (none of those) and I usually value your opinion but also gartner has its catches. What would you suggest instead of clearcase?


    I have to agree with the others, ClearCase blows big-time. Where I worked we needed a special trained person to tickle the repository's balls on a daily basis just to keep it running.

    Has anyone ever gone back and looked at Gartner's track record? I mean look at all their recommendations and see how well they have done over the years? It seems to me they often give really terrible advice.

    Peter Lin is basically a super-genius. I'd trust him over Gartner any day.
    oh man that's too funny. I'm no genius by any measure. only thing I qualify for is a loud mouth. peter
  22. Having used Clearcase in numerous projects since the early 90's I would say that it is pretty darn sweet, *especially* for branching and merging. That said it's really only applicable for larger organizations who can afford and have the organization structure to support it. You need to have someone on each project who knows how it works and can answer questions for noobs. It's really easy to get messed up if you don't know what you are doing. If you do know what you are doing it lets you do some very sophisticated SCM. See http://www.scmpatterns.com/index.html for examples of the types of things a SCM with proper branching/merging enables. I've been using SVN on my last bunch of projects with small teams and I've been happy. I've only missed ClearCase a few times.
  23. Well, having gone through ClearCase and CM/Synergy, and also having exposure to working with SCCS, RCS, CVS and SVN, I'd say that your opinion about them, can really vary based upon: 1) In what order you got exposed to these SCM tools. 2) Whether or not you had to deal with replicated SCM databases, and work with a large, geographically distributed team. 3) How much time were you given to ramp-up on these tools, whether or not you had decent coaching, and was the project patient with your mistakes and someone to correct the initial fumbling 4) How much of the total development time, did u have to work remotely, over slow / high-latency links. IMHO, of all the above, CVS and SVN appealed to me the most, simply due to their "simplicity". I had absolutely no issues in learning how to use them, however, my exposure to them was not for very complex projects, in large distributed teams, with lots of forks, branches, parallel releases. So my view, on the relative complexity of CVS/SVN and it's ability to retain simplicity in that type of context, is probably a bit fuzzy and biased. However, I'd worked with ClearCase of fairly large and complex project, with some 14-15 parallel branches, releases, cross-site development. The initial learning curve, and getting to speed on the view-concept, and file-system based view-set was a bit tough for me. Had to deliberately unlearn CVS style working, to get a hang of ClearCase, however, once you master the View-setting, I remember, everything was a cakewalk. CM/Synergy, OTOH, it's concept of folders to determine the view-set is again a bit unique and takes a steep rampup again, but once you've seen multiple SCM's, the things doesn't look as daunting. While I can't vouch for it's 100% correctness (though I never faced a problem), I found that ClearMerge tool, inspite of being bit clumsy and slow, does a very good job of doing smart merges, i.e. the remaining conflicts requiring manual attention, is much lower than most other tools offer.
  24. Well, having gone through ClearCase and CM/Synergy, and also having exposure to working with SCCS, RCS, CVS and SVN, I'd say that your opinion about them, can really vary based upon:

    1) In what order you got exposed to these SCM tools.
    2) Whether or not you had to deal with replicated SCM databases, and work with a large, geographically distributed team.
    3) How much time were you given to ramp-up on these tools, whether or not you had decent coaching, and was the project patient with your mistakes and someone to correct the initial fumbling
    4) How much of the total development time, did u have to work remotely, over slow / high-latency links.

    IMHO, of all the above, CVS and SVN appealed to me the most, simply due to their "simplicity". I had absolutely no issues in learning how to use them, however, my exposure to them was not for very complex projects, in large distributed teams, with lots of forks, branches, parallel releases. So my view, on the relative complexity of CVS/SVN and it's ability to retain simplicity in that type of context, is probably a bit fuzzy and biased. However, I'd worked with ClearCase of fairly large and complex project, with some 14-15 parallel branches, releases, cross-site development. The initial learning curve, and getting to speed on the view-concept, and file-system based view-set was a bit tough for me. Had to deliberately unlearn CVS style working, to get a hang of ClearCase, however, once you master the View-setting, I remember, everything was a cakewalk. CM/Synergy, OTOH, it's concept of folders to determine the view-set is again a bit unique and takes a steep rampup again, but once you've seen multiple SCM's, the things doesn't look as daunting. While I can't vouch for it's 100% correctness (though I never faced a problem), I found that ClearMerge tool, inspite of being bit clumsy and slow, does a very good job of doing smart merges, i.e. the remaining conflicts requiring manual attention, is much lower than most other tools offer.
    actually, my first exposure was Star Team, which had similar functionality to clearcase. the second scm tool I used on the job was sourcesafe. it wasn't until I started contributing to open source that I used cvs and svn. for the record, I didn't have the benefit of a week long clearcase training before I had to use it. I learned it as I went along and I gave it a fair chance. I had no choice, so I approached it with an open mind. It was only after using it for 2 years that I grew to hate it. Since then, I've had to use it on large projects with 8-16 parallel branches. I can get around and do what I need to, but I'm no expert. I agree that once everyone is comfortable with clearcase and follow good practices, clearcase "can" work well. The cost is considerably higher and it does require dedicated support staff to make sure it keeps running smoothly. many large insurance companies use it and have an entire division for supporting clearcase. Even if you use it correctly and follow rational's guidelines, you can still get issues with locked views. Often locked views require the admin go in and clean it up manually. Overall, I don't see the ROI with clearcase. peter
  25. IDE plugin[ Go to top ]

    If we can get plugin atleast for eclipse that would cover majority of open source workers/supporters. Regards, Prateek
  26. Re: AVS - An Open Source SCM[ Go to top ]

    If it's an "open-source Clearcase" I'll have to say "No, thanks". I probably won't live long enough to see a company happy with this kind of SCM tool.
  27. Re: AVS - An Open Source SCM[ Go to top ]

    Built on Java?!, shhh, don't tell Linus, he even has problems with SCM built with C++ and not C.
  28. I do not wish this upon my enemy[ Go to top ]

    Clearcase is the worst SCM I've ever used. I do not wish it, or any clones of it, upon even my worst enemies. Everytime I see a software shop using it, I cringe.
  29. Clearcase is dangerous[ Go to top ]

    Clearcase is the worst SCM I've ever used. I do not wish it, or any clones of it, upon even my worst enemies. Everytime I see a software shop using it, I cringe.
    Couldn't agree more. It's plain dangerous: Wrong view specs resulting in branches before you know it. Slow repository access for globalised development communities (don't get me started on replicating VOBs). And on and on...
  30. Re: AVS - An Open Source SCM[ Go to top ]

    My first experience of an SCM was pessimistic checkout using floppy disks. If you didn't have the "check out token" on your computer, all the files were read only. It was basically a batch file driven SCM, but extremely effective. However, it was hard for developers to work on the same piece of code. That said, everything was modularised so well you rarely had to. (1997 to 1999) Then I used CVS - it has it's quirks! But it makes so much more sense, and apply a little discipline (not much) and you can have large teams working effectively across your entire code base. (1999 to 2005) Eventually I started contracting for a financial institution based in Glasgow and they had fully sucked up the IBM and ClearCase approach. Everyone hated it and for all the reasons talked about above. There was no clear technical reason for using it, it seemed to be driven by the deals that management made with IBM, who were constantly sniffing around like hungry dogs. As far as I know, they're still using it. (2005 to 2007) When I started at Arum I had a clean slate so dived in to SVN. It is the best thing since sliced bread! Well, since CVS anyway. (2007 - present) However, there are features of GIT that I am interested in like that fact you don't have to have a central repository and being able to push your changes to other developers for starters. It is a lot more flexible than a centralised solution, but I haven't had a hands on try with it yet. So, AVS ... people are talking a lot about ClearCase. I am going to presume that the performance issues that ClearCase has aren't a 'feature' of AVS. As for the approach, I personally won't be using it as I much prefer the CVS/SVN approach. What I do need is a collection of open source tools that allow me to trace requirements through requirements capture -> source code -> manual tests -> defects, so that I can see where a change of requirements impacts code and tests, see where changes to code impact tests that have already been run, and so on.
  31. just a few comments..[ Go to top ]

    Hello all, actually, I never used ClearCase, but I know concepts are close to Continuus. As far as I am concerned,I have used Continuus for a few years, and found it very efficient and quite easy to use. forget about ClearCase for a while, since I did not start AVS project as a concurrent alternative to ClearCase, it was just an example. AVS targets small and medium companies which cannot afford paying the price of such expensive tools, while providing the branching per file approach, which is the basic need for configuration management. Version management is much too basic, and provides a lot of constraints. Actually, this is not the only benefit. AVS also provides the same development task concept as Continuus, which helps grouping files modified for a dedicated target. Hence, you can work for instance on many bug fix at the same time with many differents tasks, and commit at the end each task individually without confusion. A lot of people are looking for such feature over SVN, as can be read on development forums. With SVN, you just cannot do this: if you work on many bug fix, when commit time comes up, to make thing clean, you should make many commit, each one with the dedicated files, but then, how can you remember which files should go on each commit? At the time you check out a file on AVS, you know what you intend to do, so you check it out on the dedicated task. When the job is done, you may have forgotten all the details, but no matter, you just have to check in the task. SVN and CVS are very popular tools, but IMHO, they keep developers with their bad habits of not planning what they have to do. When I was using Continuus, I often avoided very difficult merge when check-out showed the file already in a working state. I tried a lot of tools on the market place, and none of them proposed this early conflict detection way of thinking with a reasonnable price. So how's AVS project started..
  32. Re: just a few comments..[ Go to top ]

    At the time you check out a file on AVS, you know what you intend to do, so you check it out on the dedicated task. When the job is done, you may have forgotten all the details, but no matter, you just have to check in the task.
    In my experience, such approach is good when you work with "dumb" files, such as PL/SQL scripts, single, unrelated documents or working on bugfixes at a (very) later stage of project lifetime.

    However with "smart" files (like e.g. Java) or during day-to-day development, usually changes in one place affect other files. Sorry, but it's very unnatural to check out, refactor, check in and a moment later to check out under another task. When working with CC, I've always ended with tasks such as "asd" just to keep my nerves calm...

    And by the way - ClearCase was very often so smart, that it put some extra "}" to my Java/JavaScript code and once it changed my DER encoded certificate into a PEM encoded one :)
  33. Re: just a few comments..[ Go to top ]

    Sorry, but it's very unnatural to check out, refactor, check in and a moment later to check out under another task.
    Wel, this is your opinion, but as far as I am concerned, I do not find this so unnatural at all, and the time you save with early conflict detection brings a direct ROI, when the tool you are using holds a commercial licence. In a more general way, when you work in a team, it is quite usual to plan what you need to do, and write specs, isn't it? At least it should be... Checking-out files before you update their contents is just the same. You first make an analysis of a new feature/bug impact within your code, then you check-out the files you need to change, all on the same task of course. And if you forgot some files, you just check them out on the fly. In case of conflict, you get informed and keep the ability of creating a parallel version: at least you know you will have to do a merge before, and not once you have finished your work. In case the merge of a given file is known to be difficult or risky, you always can choose to wait your colleague to check it in. Naturally, AVS allows resynch, i.e. you remove locally the read only flag of your files, do your job on your side without telling anyone what you are doing -what developers almost always do with SVN, isn't it right ? :)- and bring them up to the repository at the end. But you will loose the benefit of the early conflict detection, so in the end, this way of working is allowed but strongly discouraged within AVS.
  34. Re: just a few comments..[ Go to top ]

    This works well for a waterfall like development, where everything you are gonna do is well defined, which means tasks can be well defined and the files you want to check out are known. Things start to go wrong even in such environments when everyone needs the same file at the same time. i.e. struts.config The check-up-front system (locking) really breaks down when you do agile-like development where tasks are broadly defined and refactoring is encouraged. I've been using SCCS, RCS, PVCS, CC and SVN. But in general systems like PVCS and CC are more hindrance than help in developing agile like. Having a specialist on the team helps but is a project-risk. The only thing I liked about CC was the merge tool, that was especially handy when merging branches with many changes (something not encouraged in agile like projects). The mark as merged feature can be very usefull. Remember not to use automatic merge though, since CC will screw you up, as noted by a previous poster. WJ
  35. Re: just a few comments..[ Go to top ]

    Things start to go wrong even in such environments when everyone needs the same file at the same time. i.e. struts.config

    The check-up-front system (locking) really breaks down when you do agile-like development where tasks are broadly defined and refactoring is encouraged
    You may not know all the files you need to change, this is right, but where is the issue about that? When you see another file needing update, you check it out, and that's it, no? I don't know how all the SCM and version management tools handle the case where all want to update the same file at the same time, but for sure locking is not a good choice. But AVS -as Continuus- does NOT lock the file at all. What you get is quite simple: when you check out your file, say struts-config, if someone else has already checked it out, you just get a warning. Then you choose to go on a parallel version (for that file only), or wait. And of course, you can get more than 2 parallel versions at the same time. If you go on a parallel versioning, there is not much trouble, the last one who checks-in just has to do the merge, and all the these SCM tools come with a 3-way merge that usually behave just fine. So, honestly, I don't see any issue about cheching out, that would lower the development efficiency. Most of the people I know who worked with Continuus agree on this point. And those who do not had bad experiences because their Continuus instance had setup troubles. This software is known for its management complexity, and here AVS also comes with very simple setup and administration.
  36. Re: just a few comments..[ Go to top ]

    But AVS -as Continuus- does NOT lock the file at all.

    What you get is quite simple: when you check out your file, say struts-config, if someone else has already checked it out, you just get a warning. Then you choose to go on a parallel version (for that file only), or wait. And of course, you can get more than 2 parallel versions at the same time.
    That's almost exactly how SVN advisory locking works. You can either 'steal' lock, wait for it or ignore it. The end result is same.
  37. Re: AVS - An Open Source SCM[ Go to top ]

    I've used clearcase daily basis for three years and it sucked hard so much! Now I'm using svn and git and hoping never look back again! I still like to have mercurial a try sometime, as i only heard good stuff from people who used it. Rgrds, JV -- julioviegas.com
  38. Re: AVS - An Open Source SCM[ Go to top ]

    Hi Julio, Ok, it seems ClearCase is not so popular, no problem. and what about AVS, which is actually the topic of the current thread ? Did you have a try ? Pierre
  39. Re: AVS - An Open Source SCM[ Go to top ]

    Hi Julio,

    Ok, it seems ClearCase is not so popular, no problem.

    and what about AVS, which is actually the topic of the current thread ? Did you have a try ?

    Pierre
    Right said. I personally like ClearCase very much. I used it and still am using it in a lot of distributed teams, multi-branch projects and it actually rocks - sure, it does require a lot more configuration (process design, PERL scripts) but it SCM and release management become a breeze after that. However, back to AVS. The features look promising. I also like SCMs relying up on relational databases (did not have a look at the schema, still). I will try to install it on DB/2 and see what happens. Will be back shortly. Alessandro
  40. One of the most important choices with a project is the style of workflow. There are a number of philosophical questions to answer - do you confront change early, do have code reviews, can a developer review their own code, do you lock files at code review, do you mandate testing before submitting for review, do you mandate testing before integrating to base line. If you are serious about software development, some of the questions are no brainers. For a few years now I have been in a team using the open source tool "aegis" (http://aegis.sourceforge.net/) which supports your choice for many of these questions. We use it on large and small projects. It is not without its quirks and it was developed in the early nineties. I would hope that the developers of any new SCM would have a look at aegis and see what features should be brought into the 21st century.
  41. You are right on this point, the workflow should be customizable. Precicely, AVS lets the user define his own set of change request life cycle, so you can link one or another to each project, depending for instance on its type, criticity, etc.. I intend to make some additional evolutions, so change requests can have custom fields for example. AVS could then easily fit for documentation management for instance. cheers
  42. comments on comments[ Go to top ]

    re: message# 302164 ("However with "smart" files (like e.g. Java) or during day-to-day development, usually changes in one place affect other files."), this doesnt sound very smart at all -- if changes in one place affect others, you're doing something more fundamentally wrong that no magic tool will fix (disclaimer: yes, sometimes it is unavoidable, but if that's your daily experience, do some remedial work in design) re: many comments on locking and 'slowing down' developers: this is a feature. the frenzy to do too much too fast is the biggest problem in s/w development. partly it's because of pointy-hair management in commercial environments, and irrational exuberance in open source projects. here's reality: haste makes waste. adding 'cool' stuff because you can often breaks things for users. example: ubuntu was once a good distro but has gotten the redmond syndrome of too much 'upgrade' pressure with not enough attention to compatibility -- actually most of the linux world has deteriorated this way: too much dependency hell in the style of microsoft dll hell everybody: slow down! think! a tool which encourages sloppy cowboy gonzo heroics and expotential n-way merging is madness a tool which forces developers to communicate and think is good locking is the only sane way to do scm -- i dont' care how many fanboys don't understand or like this -- facts are facts and reality isn't a popularity poll