Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
After a recent "accident" at work, whereby some bugs that previously had been fixed were reintroduced, I was asked to document a set of guidelines for the use of source code control (CVS in this case).
What do you consider to be best practices for using source code control? In particular, how do you manage branching and labelling and how do you ensure that the current production release can be patched while continuing to develop new features? For context, the team size is up to 10 developers in two locations.
8 Commandments of Source Control pretty much sums it up.
On the topic of branching and labeling what we do at work is:
Labeling
When ever an environmental release is done it is labeled with at the very least the date of the release. All (related) bugs are then set so that the "resolved in release" is this label.
Branching
Only created on an as-needed basis. A branch is done off a label so that a change can be done against a previously released version (ie, fixing a bug on production without including all other bug fixes)
Eric Sink already put one together in his Source Control Howto.
I'm not sure that I would put "CVS" and "best practice" in the same sentence. There are many other, better, more modern choices for source control that are well-supported by the community.
The mainline model. The tofu scale.
Read this: http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf
update as often as possible(depeding on the project growing speed) this way fixed files wont be able to be reintroduced.
Intruct the developers to perforn an update before comiting.
There are different kinds of workflows, you will have to consider which best meets your team needs.
Also I always recommend the SVN Book.
The book "Pragmatic Version Control (using Subversion)" is a really nice place to start. Even though its examples are specific to Subversion, it's a good intro to all the important concepts and practices.
We try very, very hard not to branch. If we do create a branch it's a team decision and is carefully scrutinized. So I guess the practice would be "don't branch lightly".
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Many a time do I find myself pointed out to use some code in some github repository, and I find it hard to asses whether I should trust and use the code.
Assuming The code is an answer to my visible needs, what other parameters should I check in order to decide if using the code is a good idea?
You should check:
documentation - Is everything clearly documented? Would you need support from the author to use the code?
activity - Sometimes authors could not constantly push updates to the library, but it is important issues and pull requests are resolved rather quickly. Common bugs often are resolved by others in a pull request, but if it's not merged it's rather hard to handle all the forks.
Also you should check the Pulse page in the repo. It will show the activity in issues, commits and releases.
extensibility - You may want to do something different with the library. Or you may want to build something on top of it. You should check the API (the public interface), the configuration and whether some components could be changed with something else (think interfaces and the composite design pattern).
tests - Unit tests are important. You should write tests for your own application. When you use an external library, make sure it is well tested so you use a component which will work the same when you update it or use it in a different environment. If the code is not tested you should not use it. Unless you wrote the tests yourself.
You can check out the chrome extension DevGib that I wrote. It automatically rates Stackoverflow questions and Github repositories before accessing them, by showing a small colored icon next to the link. It's still work in progress but it does the job for me.
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 3 years ago.
Improve this question
Is there any version control software with the functionality of Git, but which is not under a viral license? - A "viral license" being, by my definition, one which requires derived software to be under the same or an equally-restrictive license.
I'm not interested in an argument on or discussion about the GPL; it's outside the scope of this question and website.
Thanks.
Fossil is (and Codeville was) a BSD-licensed distributed revision control system.
Note that unless you're actually modifying the version control software itself, the license doesn't affect you; you're free to develop non-GPL'ed software using a GPL'ed tool to manage revisions.
The other options are :
Perforce
Bazaar
SVN
CVS
UPDATE:
Since 2 years passed since started professionally working with git (after 20 years of not-git...) I can say this:
GIT has it's advantages when it comes to merging code bases between branches and multiple users. Once you master it, and learn to ignore its - sometimes utterly confusing command line UI - can be easy to work with.
On the downside, GIT IS complex to understand and LEARN. There is a long steep learning phase, especially if you work from the command line in multiply branched repository (the common and the recommended approach). Working with UI tools like InteliJ IDE's can hide some of the details, but these require their learning attention and time too + some not so basic GIT knowledge. And this knowledge is required by ALL members of your team.
OLD AND (not so) BELOVED ANSWER:
Forget the license... You want to NOT use GIT for so many other reasons...
If you want things to work faster for your team - stay away from GIT. Why not use SVN? It is supported by any service that supports GIT, and is the most popular alternative to GIT (as far as I know).
To commit/merge/manage a team in GIT it'll take you exponentially more time than other SVN/Fossil/... All in the name of advance "distributed" design, and a rich set of methods to kill your code, merge it wrongly, give you so many options to do horrible mistakes (that happen to pro's and newbies alike), and do simple things the HARD HARD way. Were in reality it only serves the ritual hungry souls of geeky programmers, who would otherwise have to go home late and face the empty walls of their houses... (poetic answer too).
REALLY - It would actually be funny if it wasn't the number one pain-in-the-arse time killer in the office. And once you go GIT you can never go back, so my advice, don't let the geeks have it. Keep it out or pay the price.
And, yeah, I know the crowd here, and I am more than willing to loose a few points. It's not like it means anything real.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
when starting with a project and using source control i find it hard to separate the things people are working on so they don't either write duplicate code or think it should be named one thing and so on.
this problem diminishes over time because the general foundation is in place and it's easier to separate the tasks so they don't overlap as much
how do you manage working with source control in the beginning phase?
EDIT:
I can see that it don't really have anything to do with source control, but it gets more apparent when you have source control too. so the question becomes more along the lines of "how do you manage to separate the tasks so they don't overlap too much. I think it's really hard and i haven't really seen much about how to do it.
Well, as far as source control goes, somebody needs to take the lead and set up the basic structure of the project, directories, etc. and communicate it to the team. On projects I work on, this is usually an architect or senior developer, someone who knows the best practices for project organization for the team/company.
With respect to avoiding having multiple people working on the same tasks, that's a project management function; someone needs to determine what tasks need to be done, and communicate it to the team. If you are working in an agile/scrum environment, the team may divide and hand out work items amongst themselves, but in either case you need to communicate to avoid doing the same work twice.
EDIT
To address the issue of multiple people working on the same task, I tend to work on smaller teams, 2-6 people; in this environment, I have had a lot of success with a scrum-influenced approach using the Crystal Clear methodology:
Architect(s)/designer(s) come up with high level design
Architect(s)/designer(s) define iterations/deliveries, the first of which is a "project skeleton" which consists of architectural and back-end components and a thin slice of the app
Lead person breaks up features into 1-3 day tasks/units of work (estimated)
Team meets and discusses priority, timing and dependencies of tasks, and divides up the first set of tasks
The team has brief daily meetings to discuss status/priorities and dependencies, and change direction if necessary
With larger projects/teams, you will almost certainly need someone whose main job is dedicated to tracking status, dependencies and conflicts.
I don't think source control has much to do with the problem of coordinating people's efforts (except that it can catch some "conflicts" when people erroneously try to modify the same files in different ways -- but, that's not as good as preventing conflicts, and even just "preventing conflicts" does not per se ensure that everybody is working on what they should ideally be working right now, in terms of priorities). Coordination is properly managed with practices (and perhaps tools, e.g. Pivotal Tracker -- but, using the right practices is even more important than using nice tools!-) that specifically focus on ensuring coordination. For example, the practices that Tracker is designed to support and enhance, such as story-based iterative planning, and other compatible ones, such as stand-ups, offer ways to meet these needs.
You must be having a base version that everyone is using, check that into the repository, and then make incremental changes to the repository, make sure that everyone works on different part of the code, commit every working change, and resolve conflicts as and when they occur. That is how I would do it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Currently we use FogBugz for tracking issues and found it to be ok. I'm looking for something else that can allow end users the ability to track their cases along with us. And something that actually works well with email. I've found a few alternatives that support those features but they don't integrate with version control. We've got all the SVN hooks in fog bugz and we use them - but I haven't really found them all that useful. Has anyone found a really good reason to need version control integration with the bug trackers?
Clearly, this kind of integration is not something that is essential to the operation of the software. With a bit of discipline every check-in can be accompanied with a bug number manually, and every bug resolution can manually have a version control tag added to it.
All else being equal however, I personally will always prefer automation over 'discipline of the users', because the latter will always sooner or later let you down from time to time. Not because the users are malicious or incompetent, but simply because people cannot be 100% alert all of the time.
I find the integration of SVN with TRAC very helpful. Through SVN hooks, commits to the repository with a ticket number insert a comment on the ticket with a link to a nice visual HTML representation of the revision number, showing inserts, deletes, and diffs.
As a supervisor over a small team of programmers, I find this as a helpful tool for me to do code reviews, so I can verify that the commit truly addresses the associated issue. I wouldn't exactly call this integration essential, but it was a nice free extra on my issue tracker that I've grown to love.
It is absolutely critical for us.
Here is a typical commit log for one of our projects (sample):
Make sure filedes is cleared in child list prior to reallocating
When p->child-filedes is > 0, the child list is active and can not
be collected.
[ Impact: Closes bug 123457 ]
Note the [ Impact: ] line, which could also be "Relates-To", "Caused" or any number of other things.
This lets us use simple greps and automated scripts allowing the person committing to automatically close, or even re-open a bug.
Though we typically use Git and Mercurial, these sort of hooks would work on (almost) any VCS, especially proprietary ones that do not feature some modular plug-in that you need.
If you think of your bug system as just another part of your VCS, its really easy to see how they depend upon each-other.
Other stuff, such as fetching patches submitted with bugs is possible, too.
It is a question about your code size, and how many bugs you need to track.
And it is also really useful for non coders in the organisation i.e. managers and customer support. They can find answers to questions like "When and where was this bug fixed"...
I think it's helpful to distinguish between bugs found internal to the development organization, e.g. from peer code review, versus bugs found by a test group that is external to the development organization.
The (small) benefit to coordinating version control with bugs found by an external test group would be for historical reference.
The larger benefit is in coordinating bugs found via peer code review with version control -- by doing so you can certify that all code is peer review bug free before releasing it to external test groups; a common requirement.
FYI, Code Collaborator from SmartBear, Inc. handles this nicely.
I have found version control integration to be extremely helpful in maintaining and managing multiple versions (stable, development trunk, etc.) of a project.
Using the version control integration and a bit of discipline from coders to reference bug tickets in commits (or some pre-commit hooks to forcibly require ticket references) has allowed us to quickly and easily generate lists of changesets that are required to fix any given bug. This is instrumental when merging the fixes into various stable branches of the code.
It's not a necessity, but it certainly makes life easier for release management.
I've used SVN + Trac and Atlassian's Jira product with Fisheye SVN plugin and have found both tools to be very good. Trac seems to be a bit simpler, but very easy to use. Jira, in my opinion, had a nicer look and feel and quite a few more bells and whistles, but was almost too much at times.
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 3 years ago.
Improve this question
What tools or approaches would you recommend to a 'one-man team' to keep organized?
I'm doing research that involves a lot of coding, writing hundreds of throw-away perl scripts, C++ binaries that get used until I find some better approach, large amounts of data that gets preprocessed in different ways, where some new preprocessing makes the old way obsolete -- until I find out that the old way was actually better, and so on. My work is inherently a moving target, as I have to try many things out, and often none of it is perfect.
It's not a completely chaotic situation, but it's also far from perfect. Are there general approaches that you would recommend in such a situation? I do use SVN for my code, although not for the different versions of the data because that gets too big. It's hard to keep track of all the scripts and binaries, so I always comment them, write down how I ran them etc. But I'm curious if you have some additional ideas.
(I work on a linux system.)
I'm using a wiki (TiddlyWiki in my case, as that runs absolutely anywhere - all it needs is a browser with JavaScript) as my "engineers notebook". Almost anything goes in there - lists of questions (and later on their answers), procedures (steps by step instructions), notes of what I put where (might work for your "data"), phone numbers (easy to find with a full text search), anything goes.
As my tasks are not that code-heavy, I'm even using it to store code-snippets (mostly SQL statements for me). Using a "real" versioning system is better if you want to keep track of different versions. Other than "use it" I can't offer specific advice for this area.
However, what has been important for me in GTD fashion: Use a simple system for almost everything. That way, the time to search for something and to decide what to put where is cut down.
Keep all your code in your Version Control System, and create build/run scripts for each. Your data you are going to have to carefully file away (since you don't want to put it in SVN).
The other thing I would add would be a wiki so you can make notes quickly about each test/script/application.
why not checkout some opensource projects to see how they organize their code bases?
even though you are a one-man team. it'd be smart to organize your project so it would be easy to add more programmers.
also if you're worried about filesize for data files you might want to checkout git. the index size is usually a lot smaller than that of svn.
Version Control is a must, as others said. Keeping descriptive labels of milestones on Version Control is very very helpful I think.
Also as IronGoofy said, I keep my snippets in my Personal Wiki TiddlyWiki, I uploaded it to my website, so I can access it anywhere, anytime.
As an additional option you may think a Time Tracker application. There are many free Time Trackers. I use ASP.NET's Time Tracker Starter Kit. You can keep evolution of your software, bugfixes, milestones.