Related
evaluating if PSCM is right for my team. Team is concerned about changing how they work with code and are understandably reluctant to stop using GitKracken, artists want PLSCM and Gluon.
nothing. asking before buying.
na
na
I'm the founder at Plastic SCM, so I think I can give you a good answer about how we interop with Git.
Well, fist it is worth saying that Plastic is not based on Git. It is a full version control stack, we developed it from the ground up.
Our secret sauce is that we can do a bunch of things that Git can't, or at least that's what we try. Things like good handling of file locks, big files, ability to work not only distributed (Git style) but centralized, and a few others.
That being said, it is not our goal to have developers using tools like GitKraken on top of Plastic, because basically we develop our own GUIs, and most importantly, because GitKraken is heavily dependent on the underlying Git commands and libraries, which are not compatible with how Plastic works.
So: while it might take some time initially, we really prefer if developers try to use Plastic GUIs.
There is a workaround, though: every Plastic on-premises server can act as a Git server. So you can use GitKraken on top of Git, then push/pull to Plastic. Not our favorite way of working since then developers miss many of the advantages in Plastic.
Hope it helps and do not hesitate to ask more questions :-)
pablo
I need a little bit of help deciding which project host (if any) to move our currently existing project to.
We currently have an SVN (but willing to migrate if necessary) closed-source project existing on Assembla. We're wondering about moving because we want to open source our existing project and:
We don't have the resources to actively promote our now open source project, and suspect that the project hosting we select might influence how our project is publicized. If we move from assembla to github, how likely is it that our project will get more attention?
We want it to be as easy as possible for new developers to pickup and start running.
Our project is also going to need very extensive wiki documentation, as it is a very complex enterprise web application framework (somewhat similar to spring). Does it make sense to put that documentation at the same place as our repo host? Or should we have a separate website for that? We also would like to have a blog as well as a forum. Same question for those.
Help?
We don't have the resources to actively promote our now open source project, and suspect that the project hosting we select might influence how our project is publicized.
Might - and might not. You can see a lot of solo-projects on any source-hosting
We want it to be as easy as possible for new developers to pickup and start running
Assembla is very good choice in this case. Do not be in a common disease Git-mania. Really "big community" in case of Github is just common marketing cheating, no more - it's not your community
Assembla have most needed (for big complex project) tools, compared to competitors. Pull requests on Github implemented better, yes. But I can't recall any other advantages. Support of almost all modern widely-used SCM (except Bazaar) is big plus also.
Around community size: Assembla have big plans of expansion to million users in nearest years (two, AFAICR)
NB: You can think about changing SCM to (some) DVCS - forking|merging are more natural in these systems and it will give one more level of freedom to contributors without big headache for any side
I think your project would get more attention being on github or bitbucket and developers would be able to easily clone from either host using git. With that said, you could try to promote it on sites like Hacker News.
Since your wiki would be very complex, I think a seperate website would be more suitable.
I'm a college CS freshman who wishes to learn a version control system well. Currently I'm looking at Subversion, Perforce, and Surround SCM.
I would be integrating the system with Eclipse, on a Linux platform. The code involved would mainly be C++, Java, and LaTeX (which I'll be using Eclipse as well).
Most probably I'll be the only user, but the advantage of SVN is that it is open source, while the other two are proprietary. I've heard a lot of good testimonial on TortiseSVN, but since I'm using Linux, I'll be missing out on that.
EDIT: Thanks for all the answers. Of course, I am open to any other version control systems as well. I will be checking out Git and Mercurial.
If you're learning version control systems, you would definitely do well to consider one of the newer "distributed" version control systems such as Git or Mercurial. By limiting your scope to the previous generation of tools as you mentioned, you will be missing out on what (some) people are really using today.
For learning a system, I probably wouldn't recommend choosing a commercial offering. You will get far better support and documentation, for free, with an open source solution.
If those are your only options, definitely SVN. That's the one (from that list) that real people use in the wild.
Honestly, though, learn a DVCS. Git, Mercurial, darcs, one of them.
If you're going to be the only one on a project, definitely you should check out SVN. Get Subclipse, an Eclipse plugin for Subversion, and get used to that. Then, move on to other version control systems once you feel comfortable.
I'd like to second (or third) those that suggested Git or Mercurial (or Bazaar). Distributed version control systems aren't just good for projects with multiple contributors; I use Git for any and all projects I start, even if they're just throw-aways. Basically, your development folder is your repository - It's portable, and it's easy to add more contributors and move to a more traditional centralized workflow later on.
I recommend Git especially because it has a bit of a steep learning curve, but it has taught me so much about project management, revision control, how to merge and patch files, how to read 'diff' output, etc. It really lets you get down to the fine grained details of version control.
You might find Perforce's whitepapers worth reading, for example High-level Best Practices
in Software Configuration Management.
SVN is very easy to learn. For those people who do use Windows, the GUI version is great.
Even if you are running Linux, I would still suggest learning it because it is widely used in places such as Google Code, Python, Wordpress, etc...
Bazaar is absolutely awesome for single-person, serverless development. It takes an entire five minutes to set up, and it's working immediately. It has the power of large VCS's ... but it's easy enough to use on your own.
I've heard Git and Mercurial are right along the same lines ... but I've a=only used Bzr.
I'd recommend Subversion, simply because of its pervasiveness in open source projects. There's definitely a lot of opportunity to put your Subversion knowledge to use in open source projects, and if you do, you'll learn a lot about coding, working as a team, and about using a VCS properly in a team (which is half of learning to use a VCS, and is the hard part because you can't learn it very well on your own). Fewer open source projects use proprietary VCSs, which means you'll get less of an opportunity to use them in the real world unless you're working specifically with friends or as a job. I haven't used the other two you mentioned, but I have no complaints about Subversion, it's quite straight-forward to use.
I'd also like to recommend a distributed VCS, such as git. With a distributed VCS, since every participant in a project has a complete copy of the source repository, and has complete control over their own copy, it means that you're given greater flexibility to use the VCS capabilities. You'll find that you have the freedom to commit as often as you want, and create new branches whenever you want, which is great when you're making changes to code and you want the ability to go back to an old version if necessary. A distributed VCS lets you use the VCS as a tool to help your coding, rather than simply as a way of storing and sharing your code with others. It's also very easy to set up a new repository in a distributed VCS. With git you just run git init and it'll set up version control in the current directory. How easy is that?
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 10 years ago.
We use Trac as our bug tracking / development / wiki system and I was wondering if anyone has experience and uses some of the Trac Agile/Scrum plugins or functionalities? Anything you'd recommend?
Or would it be better to duplicate Trac tickets as dead-tree user story index cards and a hand-drawn burndown chart?
Note that I found a similar question here. Though it's specifically about Scrum. They recommend Agilo. Has anyone tried Agilo yet?
With a collocated team, I'd always duplicate user stories on index cards. A wall of cards is much more collaborative and simple to use than any software tool. And what's most important, it's in your face.
The same is true for a burn chart. In my experience, a software chart gets online looked at by a small number of people, and typically is a pull medium. A big, handdrawn poster (that changes regularly) gets noticed by everyone, and serves as an incubator for ad hoc discussions.
It's also quite valueable to be able to point at them during your daily scrum meeting.
This is how we use Trac for our scrum like sprints:
We use the milestones in Trac to identify sprints.
There is a default Backlog milestone where we gather all new tickets.
Before each sprint we move tickets from the backlog the current release.
On the milestone page, we can add retrospectives and other info about the sprint using wiki syntax.
So just the default Trac functionality without any plugins for now to keep it lightweight. As we get better we may add features like burndown charts or maybe switch to another tool, but we want to get the proces in place first.
Answering late, but this more of sharing my experience with Trac+Agilo so far.
To quickly answer your question, perhaps Agilo is the best option available for Agile development with Trac.
Now comes to install and usining install was just very easy. We used their latest release 0.7.3.3. It installs flawless on Trac 0.11 and Python 2.5. Don't forget to install libjpeg and python imaging library. It would be useful to note that we used virtualenv which took a made things easier.
Further usage is very simple. For wiki I kind of prefer Trac's old clean look over Agilo's customization. Other than that all things just works.
On thier mailing list I have noticed that they are planning to offer multi-project support in future. In all I recommend Agilo plugin for Trac.
Yep, I installed Agilo on our Trac installation.
Seems very cool, includes nice burndown charts.
Unfortunately I left the company where I installed it before I could get any serious usage out of it.
Installation was a pain (Ubuntu Ibex) - I documented precise steps on the Agilo Google Group.
The problem (as always) is integration into the business end of things that PMs and CEOs like to see (e.g. estimated vs actual hours). There are (as has been mentioned) other products out there that cover this off (FogBugz covers this off I believe), but I (and the team) love Trac so we worked around this.
Oh, one more thing; it looks like it introduces quite a lot of overhead (i.e. you have to spend more time in trac to get the most out of it), but like I say I didn't have an opportunity to really use it in anger.
We used Trac before with a burndown plugin then went to Redmine. We've found Redmine to be miserable for repository viewing and the issue interface. We're actually looking to move back to Trac again.
Bitten is a Trac plugin for continuous integration that can be harnessed to do automatic builds on check-in, which provides a critical part of the Agile process (rapid feedback). I haven't used any other plugins for Trac personally, so I can't comment on them. However, the native Trac functionality of milestones could be leveraged fairly easily, I suspect, to be used as iteration markers (where each milestone represents the end of an iteration). Since milestones can be used to mark a 'due date' for features already, you shouldn't need much in the way of modification to use them as such.
From there, using tickets as user stories, and tying them to milestones (I'm sure this can be done manually at worst) would give you a basic method of tracking velocity and keeping the team aware of progress (and changes that need to be made as well).
We use the Trac wiki for:
List of requirements for each feature
List of technical specs (if any) for the features
List of Releases and their features
Deployed environments, with links to all instances
There's a macro for making web requests, so we can list which version, etc. each env have
(there's a GraphViz plugin which is quite helpful for simple drawings)
There's also a ticket in the ticketing system for each "feature", for keeping a gross backlog and the current/next sprint planned.
Then we write a bunch of cards during sprint planning for each feature.
There's also a more operational side to things. We keep one person each sprint on Ops, so we have one person who's dedicated to be interrupted by people outside the team. The rest of the team can focus on delivering features.
Each bug/ops task gets a ticket, but as soon as we start working on it, it gets a card and starts moving across the board. That way it gets visibility and we don't forget to involve the testers, etc.
Scrum is pretty tactile, so I don't think it would work great to put too much stuff outside of the physical working environment. But in the end your team needs to find a balance that works.
For something completely different, the best way to do Agile Development with Trac may be to simply migrate everything to Redmine. It supports Trac's core features with some extras including multiple projects, Gantt charts, forums, DCVS, etc. though it looks like it's not completely there yet. Some good things in the pipeline.
Daniel Srb (in the comments) has a redmind agile plugin he's been working on that looks promising. You may be able to contact and see if he's planning to release it (was a long time ago).
We've had success using two products in concert in the past, Trac for tickets, xplanner for planning.
Agilo for Scrum rocks, the latest versions are using client side generated charts, so there is no dependency anymore, much easier to install :-) agile42 just release a Pro version that enriches the Agilo experience with a nice and intuitive Planning Board, very cool screencast :-)
We recently started using Scrumban.
Basically a Kanban board, with the daily stand-up meetings covering the classic Agile Scrum questions - what did you work on the previous day? what do you plan to work on today? do you have any blockers?
We do this around a physical Kanban board, it is great for visualizing the work flow and for team synergy, but we also wanted a digital form of our Kanban board to be able to double check trac usage vs. the physical board.
In search for something that would work, I found this clever post on re-creating a digital version of the Kanban board in trac.
It is very straight forward and simple, I was able to easily manipulate this approach for our work flow, and you could probably tailor it to your Agile Scrum iterative approach (or if your able to ditch the time boxed approach, give Scrumban a try).
What would be the best version control system to learn as a beginner to source control?
Anything but Visual Source Safe; preferably one which supports the concepts of branching and merging. As others have said, Subversion is a great choice, especially with the TortoiseSVN client.
Be sure to check out (pardon the pun) Eric Sink's classic series of Source Control HOWTO articles.
I'd suggest you try Subversion, for example with the 1-click SVN installer. Try searching SO for "Subversion", and you'll find loads of questions with answers that point to good tutorials.
Good luck!
I'd go straight for Git. I've used subversion before, but always felt like I was doing it wrong. Git made sense from day one.
Useful resources:
Linus Torvals on Git
Scott Chacon "Getting Git"
There are a few core concepts that I think are important to learn:
Check-ins/check-outs (obviously)
Local versions vs. server versions
Mapping/Binding a local workspace to a remote store or repository.
Merging your changes back into a file that contains changes from
others.
Branching (what it is, when/why to use it)
Merging changes from a branch back into a main branch or trunk.
Most modern source control systems require some knowledge of the above topics and should help facilitate you learning them. Then you have distributed source control, which I don't have any experience with but is supposed to be fairly complicated and may not be suitable for a beginner.
Subversion is great because it has all of the modern features you'd want and is free.
Git is also becoming an increasingly popular option and is another free or very low cost alternative to Subversion. Knowledge regarding the concepts of branching and merging become critical for using Git, however.
You can use unfuddle as a free and easy way to experiment with both Git and Subversion. I use it to host a couple of subversion repositories for some side projects I've worked on in the past.
I'm not and advanced source control user, but I'm learning. Here is my experience with source control products:
A long time ago, the company I was working for at the time decided to use source control. They introduced the concept to developers and got eveyone willing to give it a try. They chose to use PVCS, and implemented it. Before too long, developers would have to coordinate to lock/unlock modules and objects and we really didn't see much benefit.
A few years later, I was playing around with making an open source project and at the time rubyforge was offering CVS repositories. I tried it out and it was marginally better than PVCS. Granted I was the only one using the repository. I did however become frustrated when I tried to rearrange the structure of my files because I didn't like the way I had initially imported them. It didn't really work out in CVS.
A few years after that I was working on another personal project and my web hosting provider offered easy to setup Subversion (SVN) repositories. It took me a little bit of research to get it up and running correctly, but once I got past the initial learning curve, I liked it.
Not long after that I realized that I liked having source control and that my current job didn't have it. So I evangelized, and after a long period of time, my team implemented Source Safe because we work in Visual Studio and are generally a Microsoft shop. I was eager to use it, but before long I found that I was losing files and that Visual Studio was putting things in the wrong place and that I'd work on a project for a while and then go to export my work to another location and find that it either wouldn't export or would only export some of the projects in a solution. This made me realize that even though I thought I was using a "version control system", the copy of the code that was most secure, robust and complete was my working copy. The exact opposite of what source control is supposed to do.
So last week I was so fed up with Source Safe that I went searching. After looking into a few solutions, I decided to try git. I won't say it's all been roses, since I have again had some learning curve to get it to do what I want it to do, However, I have liked it enough to convert all of my work and personal projects over to it. One of the really nice things about it is that I don't need a centralized repository so I can use it without going through a ton of red tape at work to get it installed.
So in short I would reccommend git, I use Mysysgit in windows and it has the added bonus of giving me a bash shell. On Linux you can just install it from your package manager. If you don't like git, try subversion. If you don't like either of those you probably won't like CVS or PVCS either. Under no circumstances try Source Safe, it's awful.
I found http://unfuddle.com saved me messing about with installing SVN or git. You can get a free account in there and use either of those - plus you can use your OpenID there.
Then you avoid having to mess about setting it up right and focus on how you're going to use it!
Vault from SourceGear.com is superb. It is free for single users and provides a superb VS 2005/2008 interface. I love it!
rp
#Ian Nelson:
I agree with you that Source Safe is bad as a source control system, but keep in mind that using Source Safe is a lot better than "carrying around floppy disks" as Joel Spolsky said.
For a beginner it might not be a bad idea, since the cost of having no source control at all is a lot higher.
Each tool has it's strengths and weaknesses. It's very much a question of what your requirements are. Unfortunately with this issue, like many others, it's often not the best tool that is selected but the one that someone is familiar with. For instance, if you don't require many branches and your team is small and local, almost any vcs will do the job (except SourceSafe). Things change if you need branches (which almost by necessity means you also need to do merges), your team is distributed, you need advanced security (subcontractors are not allowed to entire source tree), task tracking, etc. There is also the question of cost in three different ways: cost of licenses, cost of maintenance (some tools are so complicated that you in practice need someone just to control the repositories) and cost of training.
Therefore suggesting one tool over another is like suggesting what would be the best programming language.
Just some pointers:
StarTeam is the easiest of the tools
I have used. It required very little
training. I got a one-day training
since I was to be the maintainer.
This maintaining took me less than 30
minutes per week. Users I "trained"
by writing a two-page manual and
after that I had very few questions
to answer.
Continuus was the other end of the
scale as far as ease of use is
concerned. On the other hand task handling was great and it offered good support for release management. Trouble is, even as a release manager I never thought ease of making releases (it was once you learned how, but that took a considerable amount of time) should be more important than the daily work that developers do.
Merging and branch creating differs
wildly between tools. Some tools make
this simple, like git and ClearCase
(although the latter is very slow)
some basically force you to do the
merge by hand. If you need to do
merges a lot, the cost can get high.
ClearCase was also expensive in all
three categories mentioned before
(although it has to be said we used
all the advanced stuff which isn't
necessary). Git on the other hand
lacks a good UI and some of concepts
differ from what you might be used
to. Git's security features are also
lacking (gitosis addresses some
issues but not all).
Most tools I have used are also quite
slow. Tools like PVCS/Dimensions was
just slow, no matter what (basic
things like opening a directory in
the repository), some very slow in
more specific ways (like ClearCase).
From the tools I have used I would select StarTeam if your developers are not very experienced (and if you don't mind paying the license, which is quite expensive) and git if you have some experienced vcs guys onboard who can set up the environment to other guys. Mercurial also looks like an interesting competitor and seems to have slightly better UI's.
Continuus, PVCS/Dimensions and ClearCase are just too slow, too complex and too expensive for almost any project. If someone insist on selecting one of these, I would go for ClearCase.
I haven't used Subversion which many seem to like (yet, I have a feeling this is about to change in the near future) so can't comment how it compares to the other tools I have used (usually as a build and/or release manager).
As for the first tool to choose, problem with Git, Bazaar and Mercurial is they are distributed vcs's. This is different from the traditional server-client model where you have a central repository. For just learning the stuff I would recommend also reading about the concepts. Branching for instance is something that you might not understand correctly just by trying yourself (there are different branch strategies for different situations). Plus it is very different if you are the only one accessing the repository, merge conflicts for instance wouldn't be a problem (you might get to see them but you would easily also fix them since you know the code in both branches). Of course you would learn about check outs, check ins, and such but I don't think these issues are particularily difficult in the first place.
Added problem with vcs's is that they tend to use different terms. In StarTeam which is otherwise easy to use they for some reason insist on using the terms "check out" and "check out and lock". The latter is what most people think the first does. There is a reason for this (you can edit files even if you don't have an exclusive lock), but it would still make much more sense to call these "Get" and "Check out" to avoid confusion.
Anything, but I would learn a modern system like git or subversion myself. My first VCS was RCS, but I got the basics down.
Well, if you are just wanting to learn on your own, I would say you should go with something free, like subversion. If you are a company who has never used source control before, then it really depends on your needs.
My first exposure was CVS with WinCVS as a client. it was horrid. Next was Subversion, with TortoiseSVN and Eclipse's integration. It was intuitive, and heavenly. I think that using CVS with TortoiseCVS and Eclipse's would be nice as well, though I prefer the way SVN handles revisioning. The entire repository is versioned with each check in, not individual files.
I'd also recommend Subversion. It does not take too long to set up, it is free, and there is a really good book available online that goes over the basics as well as some advanced topics: http://svnbook.red-bean.com/
Subversion with tortoisesvn. (tortoisesvn because you can see a lot of what goes on visually and will provide a good jumping off point for the command line stuff. ) There is tons of documentation out there and most likely you will see it at least one point in your career. Almost every company I have worked for and interviewed with runs SVN.
If you're looking to learn a commercial product while getting started Perforce provides a free client and server, with the server supporting two users and five client workspaces.
At my previous place of employment it was used religiously not only for code by our programmers, but for art assets and game levels, and my own documentation.
Subversion is good place to start with. It is very stable and modern version control system.
Best online resource to start learning about Subversion would be Version Control with Subversion. There are lot of choices as far as server and client softwares are concerned. I personally prefer (for Windows environment).
VisualSVN server
TortoiseSVN shell-integrated client and
AnkhSVN Visual Studio Subversion Add-On
Again, with Subversion there are lot of options available. Also, it is a continually evolving version control system (unlike outdated SourceSafe). It could be easily integrated with numerous automated build tools (CruiseControl, FinalBuilder) and bug/issue tracking systems (JIRA).
If you are looking for state-of-the-art version control systems, go for Git(developed by Linus Torvalds). But if you are totally new to version control systems, I would suggest start with subversion.