I was wondering which DVCS is most conducive to experimentation i.e. branching, etc. I want something where anyone can quickly launch smaller projects and refactor code quickly. I want to create an environment where experimenting is cheap and can be discarded/merged easily.
Git is known for very cheap branching, they made it so that branching was something trivial, so that, like you said, you could create branches for any little thing. I don't have experience with the other DVCSes, but I imagine they're pretty similar given their similar nature. I just know that cheap branching is one of Git's reasons for creation, or something like that. Sorry if I misunderstood your question.
Here's a section of a popular article/site giving details about git over other version control systems.
In response to your comment: On windows I imagine? I've been fine using msysgit, get msysGit-fullinstall-1.6.4-preview20090729. For a detailed walkthrough with screenshots that helped out some friends, I recommend the Git for Windows Developers series.
You could also try Mercurial, it's fast, it's distributed and it's easier to use. If you like working with a GUI try -- TortoiseHg.
Here is an analysis done by google before they integrated mercurial into google code.
Your requirements match Darcs or Git.
If you're a GUI user, why don't you take a look at Plastic SCM? http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html. It's one of the few commercial DVCSs out there and it's focused on ease of use but it has all the features you're looking for:
Excellent branching and merging support (full merge tracking, rename support and all that)
Distributed (and easy to use)
Subtractive merge support (you can do it from the GUI)
Besides:
Very good visualization
Excellent Windows GUI (check it)
Excellent VStudio integration
Related
I'm quite pretty new to the concept of CVS. However, I want to start using CVS and thus need to 'check-in' some scripts. I'm using a UNIX server and I know that CVS is installed, since doing a
cvs -v
Gives me the correct version number installed. Now the problem I have in is finding documentation to use CVS. Is there an online tutorial/FAQ someone can recommend. I've scoured Google for information and all I come across are posts for installing CVS ...
What I'm really looking for our sample commands taking a beginner from scratch like Logging in etc.
The meta-answer to your question is not to use CVS, unless you're participating in a project that's already using it. Even the CVS maintainers, as far as I understand, don't recommend it for new projects, but recommend svn instead. If you're being obliged to use it, then this answer isn't helpful; sorry.
If the decision is up to you, then you have alternatives:
svn is the system which is most similar to CVS (as noted in another answer).
Mercurial is a distributed version control system, but the distributed features aren't hugely important if, as your question vaguely suggests, you're working on your own.
Git has broadly the same model as Mercurial.
There are others (including at least bazaar and darcs), but those are the big three.
All of these are heavily used in both small projects and big ones.
I now tend to recommend Mercurial to people, and that's the one I predominantly use myself. There are holy wars possible about this, but I feel that's the one which has the best tradeoff between flexibility, good design, and usability (there's a longer version of this answer...!)
Update: there's a very good Mercurial introduction by Spolsky, which is well worth reading for rationale and pointers.
Use svn instead, lots of documentation for that.
Hmmm... a quick Google search for cvs tutorial returns this as the second hit:
http://www.linux.ie/articles/tutorials/cvs.php
I've quickly glanced over it, and Chapter 3 (Basic CVS Usage) starts with "Logging In" and seems to come pretty close to what you need. If you have any concrete questions, feel free to ask.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I work on a team with three other developers and one business analyst writing internal business applications. We're primarily building apps in ASP.Net, and do so in a very 2003-ish way. It's like going back in a time machine. Although two of the other developers are amenable to learning new things, one of the developers is not. He's the type who thinks he's the strongest developer in town, and that if he doesn't understand a new tool within 5 minutes then he just needs to build his own. He also doesn't recognize agile development, TDD, or basically any non-Microsoft-blessed tool or method. He even considers source control from anything other than SourceSafe to be dangerous. To his credit, he's a brilliant programmer, just not someone interested in software development.
So the only way I can get consensus is if a tool is really easy to use. Once we hit a single snag, he'll lose faith in a "I told you so" sort of way.
So what set of tools should I use to get us into a modern source control system, TDD, and CI? The obvious choice in my situation seems like it would be Microsoft's TFS, but I doubt I could get our thrifty and apathetic management team to spend the extra money (they already think MSDN Pro is too much).
Basically, what is the easiest set of tools to get going with Source Control, TDD, and CI for a .Net 2008/2010 environment?
I wouldn't recommend dumping all these tools and methodologies on your team at once, take baby steps. Introduce one at a time. Some will come naturally.
There are many good choices, but I can personally recommend these:
Source control: Subversion with TortoiseSVN and Ankh or VisualSVN
Continuous Integration: CruiseControl.NET
TDD tools: NUnit + your mocking framework of choice (I use NMock, though it's a bit old-school). I agree with commenter Eric that TestDriven.NET is a must-have, particularly if you want to make this easy!
These are easy to get started with because they're all good products, reasonably to very well-documented, and widely-used (so it's easy to get help).
It's always going to be difficult to introduce new tools if you can't build a consensus. Focus on building the consensus, rather than on the tools.
SVN is very good (with Ankh and TSVN), but it can be a bit surprising to people used to SourceSafe.
TDD is a technique, rather than a toolset, so you need books, blogs, etc. For tools to support it, NUnit or MSTest. Continuous Integration is a must-have. CruiseControl.Net is pretty good (though a bit difficult to configure initially). Consider also TeamCity.
Do you have a bug-tracking system?
Oh, and if your management team is that apathetic, consider quitting.
Update: you've said that they're not so much "apathetic" as "hands-off". Question: are they really hands-off, and will they let you move things along? Or are they "status quo" -- "it ain't broke, so don't fix it, and don't rock the boat"?
I think you can make a really really good case that within the last two years Agile has become completely and totally embraced by Microsoft. I know for a fact that the Codeplex, MEF, and ASP.NET MVC teams are quite steeped in it. I also think that visual studio and parts of the windows 7 team are Agile. Also consider that Visual Studio 2010 includes out-of-the-box refactorings that don't really make much sense outside the context of TDD and that Agile is the default project management template for TFS and a picture of a corporate culture that is quite different from the one of years past starts to emerge.
As for specific tools. TFS is OK for source control but I find it very heavyweight and finicky. Others have mentioned Subversion but if you're worried about MS blessings you might have better luck jumping straight to Mercurial. Its a more advanced SCM but it is now supported natively by Codeplex and has excellent windows integration. I've never used it but I am in deep tool-love with it's cousin git.
Test driven development: Start with MSTest, its not as slick as anyone would like but its not the worst thing in the world. I would also recommend MbUnit which has all of NUnit's features along with some good support for the integration tests that you will probably be writing by accident as you are starting out with testing. Oh, and if you have customization freak I would urge him to look at XUnit.Net.
Mocking: The choice is basically Rhino Mocks or MoQ. Here's a quick intro I wrote for Rhino Mocks that goes over all the basics. That being said, the trade off seems to be more documentation for RM versus a very mildly less error prone syntax for MoQ.
Test Runners: If you start out with MSTest you'll notice that you can get a significant speed boost in your test runs by using TestDriven.Net, resharper or coderush rather than the built in test runner. That being said, don't underestimate the standalone test-runners. They can be quite good every once in a while. I heavily recommend Gallio Icarus runner which comes with MbUnit.
I want to echo what George Mauer has said and suggest starting with MSTest for your unit testing. It's right there in the box to begin with Visual Studio, this will help in your cause as it's "MS blessed".
I would start with unit testing and take it from there, after a few months of "look how easier our life is now we have these tests automated" I'd take it up a notch. Consider adding something like Selenium or WatiN to the mix. Once you're rolling with that, get your CI server up. "Wouldn't it be great if we didn't have to start off all these tests manually?..."
I guess a decent SCM might be a sticking point. SourceSafe is better than nothing. Perhaps start using Mercurial or Git yourself? Show those open to the change the benefits, eventually your stubborn dev will come around when others around him are wanting to switch. Hopefully, he'll find it harder to shout if he's in the minority.
Check out http://www.viget.com/extend/effectively-using-git-with-subversion/ for ideas with mixing up different SCMs.
I also want to +1 mxmissile for saying to take things slowly. I think you'll find it very difficult to introduce all these changes in one go. It's a lot to take in at first if you're not used to it. Try to pick the part you're weakest on, or will add the most value and build up from there.
Good luck!
One tool that got me hocked on TDD is TestDriven.Net which puts the test results in the Output window. I mapped this to the F8 key and the productivity gain is superb; write a test, press F8 and see this results in the output window.
One suggestion I also have to differentiate between having Unit Tests and doing TDD. I have found that TDD can be hard to push on to a team, while; unit, integration or functional tests are an easier sell. Having a bunch of tests that saves an hour going through a manual test day after day is a big win.
After a while people will start to appreciate some new ideas if it is helping them in their daily life. Then you'll be able to introduce a build server, and move away from SourceSafe.
In .NET environments, Microsoft Visual SourceSafe is most frequently used. (but it costs). Next to that you can opt for SVN or GIT. Git is more recent (and gaining popularity). It's easier to work with than SVN once you get it.
http://git.wiki.kernel.org/index.php/GitSvnComparison might help with your decision.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
We are currently using Fitness for subsystem testing.
we are having lot of issues using the tool, few to mention
Development time for writing Fixture is more then writing the actual code
Issues around check in of the dlls so that Qa can test them
Issues in running Fitnesse for project which uses NHibernate
limited help online
We are planning to use some other tool to do the testing
Few options which we know are
SOAP UI
Story teller
I am not sure whether we will have similar problems with these tools
It would be great to know if someone has experience using these tool and could guide us
In our project we have adopted TDD so we have Nuits for unit testing.
It would be great if anyone is aware of tools/ideas which could extend nunits for subsystem testing as well.
Component testing tools are all about calling functions. Your tests cause functions to be called in "fixtures" that then call into the SUT. Any tool based on this premise will encounter the problems you reference above.
However, most of those problem are manageable. For example you should not be writing lots of fixtures. If you are, something is wrong. Secondly, your fixtures ought to be little more than wiring code to call the APIs in your application. If your fixtures are doing significant work, then something is wrong.
In most FitNesse environments the number of fixtures is rather small. For example, there are over two hundred acceptance tests for fitnesse itself, but the number of fixtures in on the order of a dozen, and they are all relatively simple.
Get help on the fitnesse#yahoogroups.com site. The folks there are usually very responsive to questions.
If you can communicate with your software using text, then I have had success on past projects rolling my own framework using expect.
The framework I cooked up stored tests as XML files, using a simple xUnit style markup. The xml files were then transformed into executable tests using a stylesheet. I ended up transforming the tests into Tcl/Expect, but you could transform them into anything. In fact, if you wanted, you could transform them into multiple languages, depending on your needs.
Several people have kindly reminded me (in the same way you remind you poor dottering grandfather about the drool on his chin) that we are in the 21st century when they inquire why I would choose Tcl over some more modern language. As it turns out, for the purposes of this kind of testing, I haven't yet found a better choice. The Tcl language still kicks butt in this area. Trust me, I didn't wake up one day and say to myself "self, what I need a test framework implemented in a scripting language everyone will hate!"
Believe it or not, I really was looking for a tool, any tool, that had the following characteristics:
Cross platform. This was non-negotiable. We do a lot of cross platform development and we already use WAY too many tools that don't support cross platform development.
Simple syntax. Say what you want about Tcl, but the syntax is very regular. I knew that some native code would probably creep even into the XML files (and originally it was Tcl only, no XML) and I wanted the syntax to be comprehensible to a non-programmer. This simplicity is a core strength of Tcl. As it turns out, it also made transforming the XML easier too.
Free. My favorite price ;-)
Writing tests as simple xml files allowed non-programmers to write customer acceptance level tests - no programming required.
Easily extended.
I did not set out to home grow this to the extent I have. Initially, I looked at established test frameworks like DejaGnu and android. Mostly they had way too many features. They were so feature laden that I didn't think they would be easy for a project to start using without a lot of up front training. Looking at DejaGnu, got me interested in Tcl in general, and after a brief look at tcltest, I almost gave up. Both DejaGnu and tcltest assume you are an advanced Tcl scripter, which I didn't think anyone at my company ever would be. In addition, I wanted the test framework (if possible) to support an xUnit type of test framework and neither of these tools did.
Eventually I found TclTkUnit, a Tcl based testing framework that is designed along xUnit lines. It was only a short leap of logic to realize I could run TclTkUnit in Expect instead of tclsh and get everything I needed.
As it ended up getting used more, I added another stylesheet to render the xml files nicely in a web browser. The test framework generated it's own documentation.
On another project we needs a very basic sim / stim environment to emulate a person throwing switches and pushing buttons on a piece of hardware we didn't have. It only took a few hours to hack the test framework to function as a simulator. Creating the framework took some work, but we felt that it did pay benefits in the long run. I really believe that these types of unforseen consequences of creating your own tools is why people in the agile community & XP in particular have always been such strong advocates.
We have adopted a Fitnesse-based but practically-code-free approach using GenericFixture (google for Anubhava to find his wordpress site) for Fitnesse.
What this allows us to do is to create "executable test narratives" using a language that is friendly to the business-side (as opposed to the technical-side). This language, which is very easily defined, practically without coding, in Generic Fixture, is called a DSL (domain specific language). So we can write our test narratives using e.g. medical terms or even in a language other than English. Basically what we get is transforming our Use Cases into executable narratives.
We are starting to use it in a large project (15 ppl for 2 years) and it seems (so far) to have a good future.
It easily allows Test Driven Development or test-creation after development (traditional approach).
It is wiki-based (Fitnesse) and its versioning and refactoring funcitonality has proven so far sufficient.
I can give more info if anyone is interested.
best regards,
Aristotelis.
We use unit-testing frameworks like NUnit to drive our subsystem tests as well - the tests don't care how they are run. It doesn't have fitnesse's document-based approach, though.
I work in Visual Studio working on sites mostly myself and occasionally I start on new features for a site and bam a bug pops up on the live site and now I am in the middle of changes and can't post a fix to the bug until everything I started to change is complete.
So I am looking for a nice an simple way to work with this type of situation - any suggestions?
Are you asking for a recommendation of a source control system? SourceGear Vault is free for single users.
I am big fan of subversion. There also plugins for VS to work with subversion repository.
http://subversion.tigris.org/
http://ankhsvn.open.collab.net/
I am in a similar situation and I use Perforce. It is free for up to two users and integrates well with Visual Studio.
Subversion is well supported and has tools for most any environment. It's also mostly straightforward to use, so you should be able to get up and running quickly.
If you need to work on a lot of separate features and bugs at the same time, you might try Mercurial instead. The tooling support is a lot less mature but I find the distributed design to do a better job of merging and facilitating work on separate issues concurrently.
But really, if you aren't using anything currently and aren't sure what your needs are, just choose one that has support in the IDE/tools you use. It will probably be Subversion.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
fossil http://www.fossil-scm.org
I found this recently and have started using it for my home projects. I want to hear what other people think of this VCS.
What is missing in my mind, is IDE support. Hopefully it will come, but I use the command line just fine.
My favorite things about fossil: single executable with built in web server wiki and bug tracking. The repository is just one SQLite (http://www.sqlite.org) database file, easy to do backups on. I also like that I can run fossil from and keep the repository on my thumb drive. This means my software development has become completely portable.
Tell me what you think....
Mr. Millikin, if you will take a few moments to review some of the documentation on fossil, I think your objections are addressed there. Storing a repository in an sQLite database is arguably safer than any other approach. See link text for some of the advantages of using a transactional database to store a repository. As for bloat: The entire thing is in a single self-contained executable which seems to disprove that concern.
Full disclosure: I am the author of fossil.
Note that I wrote fossil because no other DVCS met my needs. On the other hand, my needs are not your needs and so only you can judge whether or not fossil is right for you. But I do encourage you to at least have a look at the documentation and try to understand the problem that fossil is trying to solve before you dismiss it.
After having used Fossil for more than a year now on non-trivial development projects, I feel confident enough to weigh in on this topic.
Below is my experience so far. I'm comparing against git and svn at times, simply because I know those SCM's very well and comparing makes it easier for me to get the idea across.
I'm totally in love with this SCM, so it's mostly points on the plus side.
What I like about Fossil:
We have a bunch of machines (win/mac/a number of Linux distros), and the single-executable installation is just as beautiful as it sounds. No dependencies; it just works. Git is a messy pile of files and the dependency hell in Subversion makes it very nasty on some Linux distributions, especially if you must build it yourself.
The default Fossil workflow suits our projects perfectly, and more git'ish workflows are possible when needed.
We've found it extremely robust, even on large projects. I wouldn't expect anything else from the guys who wrote SQLite. No crashes, no corruption, no funny business.
I'm actually very, very happy with performance. Not as fast as git on huge trees, but not much slower either. I make up any lost time by not having to consult the documentation every other command, as is the case with git.
The fact that there's a tried'n'true transactional database behind every operation makes me sleep better at night. Yes, we've been through more than one horrible incident of stale and corrupt Subversion repositories (thankfully, a helpful community helped us fix them.) I can't imagine that happening in Fossil. Even Subversion 1.7.x use SQLite now for metadata storage. (Try turning off power in the midst of a git commit - it'll leave a corrupt repos!)
The integrated issue tracker and wiki are optional, obviously, but very handy as it's always there - no installation required. I wish the issue tracker had some more features though, but hey - it's an SCM.
The built-in server and web gui is simply brilliant and quite configurable through css.
We sometimes need to import to and from git and subversion repositories. This is a no-brainer in Fossil.
Single file repository. No '.svn' directories all over the place.
What I miss in / dislike about Fossil:
Someone please write TortoiseFossil for our non-technical Windows users :)
The community isn't that large yet, so it's probably hard for a lot of people to introduce it in their company. Hopefully this will change, gaining all the benefits of a large community (documentation, more testing of new releases, etc.)
I wish the local web ui had a search feature (including searching for file content).
Fewer merge options than in git (though the Fossil workflow makes merging less likely to occur in the first place.)
I hope everyone gives Fossil a run - the world is a better place with stuff that just works and which you don't need to be a rocket scientist to use.
Fossil is small, simple, yet powerful and robust, reminds me some principles of C Culture. Likable by those who develop independently and still collaborate.
Any great project should start with principles and continue them at its core as it gathers more layers (GUI, extra features).
I am impressed with Fossil and starting to use... take a look at fossil
cheers
I'm landing on this page after an year of the last post, recursive add that has been mentioned here is now taken care of.
Fossil mesmerizes me with simplicity especially after I struggled to get a bug-tracking system to work with mercurial. I need to see how to manage multiple projects, publish the repositories for multi-user access and how to do merging, manage patches etc. I get the feeling that it wont be disappointing going forward.
I'm not interested in using it for source-code version control, but I am interested in a distributed version-controlled personal wiki that I can sync between all the machines I use.
damian,
1/ yes, fossil doesn't support recursive add. However there are some fairly simply workarounds such as
for /r %i in (*.*) do fossil add "%i"
on Windows, and
find . -type f -print0 | xargs -0 fossil add --
on Unix.
2/ I saw the message about malformed manifest when you are adding a file with non-ASCII characters in the filename. The problem was corrected in the last build.
Regards,
Petr
I think fossil is really cool. The most important feature for me was easy installation, and developer friendly defaults. I currently use it to keep track of the local changes of my files. (Our project is hosted in sourceforge and kept track in CVS.) This way I can "commit" locally even if it would otherwise break the project, so smaller changes can be kept track as well.
Fossil is good. It is simple and easy to use. If fossil can provide GUI interface to check in and check out, then it would be better (prefer java gui to archive cross-platform GUI).
The main advantages of Fossil are "open source" and "use SQLite database", so somebody can compile fossil source code to make fossil work on google android platform (mobile and tablet devices).
I am trying your vcs right now.
I like the idea of having all integrated. After all, is all i want when i look for a system like this. I am an active user of Mercurial. And i couldn't find an integration with a issue tracker (I try unsuccessfully to set p Trac with mercurial in the past).
After some test i realize that:
1) "add" command is not recursively, or i can not found in the doc a way to do it
2) i write a bat (i work with windows) to add 750 files and i run it (it took a while). When a run commit it jumps with "manifest malformed"
i think you could address this issues and others making a survey like the Mercurial's one in https://www.mercurial-scm.org/wiki/UserSurvey.
you could write me at dnoseda at gmail
i am interested in you work. keep improve it.
regards
ps.: as an mayor improvement you could add something like gitstat
Perhaps an uneducated knee-jerk reaction, but the idea of storing a repository in a binary blob like an SQLite database terrifies me. I'm also dubious of the benefits of including wikis and bug trackers directly in the VCS -- either they're under-featured compared to full software like Trac, or the VCS is massively bloated compared to Subversion or Bazaar.