I am using Eclipse with the "statet plugin for R".
I am looking for a way to do collaborative development (like in google docs: allow people to modify code at the same time). Any preferred plugin for that? I have seen eXtreme Collaborative Development Environment but I don't know if it is good?
I wouldn't use a shared drive, I'd set up a source code respository using Mercurial or Git and use that. I'm sure there's plugins for those for Eclipse.
How would you stop it being a free-for-all? In my experience, when developing code you want to control change, not have it forced upon you when you aren't ready for it.
Consider this scenario. You have a hard to explain defect in your code. You are steadily debugging it, throwing different data at it, looking at intermediate values etc. You are just about to trap it when BOOM, somebody else changes some other code and your results change because of that.
Spacedman is right, use a revision control system of your choice and keep in control of change.
If you want to do something like pair programming, but remotely, then use a remote screen, e.g. VNC, with Skype so that you can explain to the other what you are trying to achieve.
I've used egit to add git functionality to Eclipse with StatEt and it works well. Allows others to edit code in whatever way works best for them (one repository, several individual repositories with frequent merges etc)
There are plugins out there that will facilitate realtime code sharing. They commonly work by having all individual devs have their own copy of the files and synching changes back-n-forth on the fly. If conflicts are found you get to decide how to resolve them explicitly.
Here is one such plugin from ECF project:
http://wiki.eclipse.org/DocShare_Plugin
I would recommend a source control system for day-to-day development. Real-time code sharing works best for holding short-term collaborative editing or debugging sessions, doing code reviews, etc.
Related
While I make some (java) code, i feel the need to experiment and change some parts of it often.
I want these changes to appear in a copy of my existing project and not the original - something like "save as" vs "save".
I have some options to do this job(below). Problem is that I can't decide which one to choose.
As a beginner to version control, I want something that is very easy, but is also used in many software companies. I already have a lot of problems with compiler and run-time errors. I hope that a version control software will not make the coding process even more difficult.
Options-
1- Make copies of my code and label them with different numbers/dates.
2- Use SVN ?
3- Use GIT ?
Besides this, are there any other version control methods ?
EDIT-
Is is possible to do SVN inside eclipse itself or maybe integrate eclipse with some SVN software ? If yes, would this be a good approach ?
I currently use SVN for personal projects and Git for group projects. The way Git handles branching is pretty slick. SVN is just really easy to set up and use (you just need a URL as opposed to a ssh login on the client side).
If you're using Windows, I'd suggest using the TortoiseSVN and TortoiseGit.
https://tortoisegit.org/
http://tortoisesvn.net/
I'd also suggest not going with the first option. Revision control is pretty important, even if you're just a hobbyist.
I'm currently working on a project that's been going on for several years straight. The development-team is small (less than 5 programmers), and source-control is virtually non-existent, and the deployment-process as is is just based on manually moving files from one server to another. The project is in classic ASP, so building isn't an issue, as both deployment and testing is just about getting the files to where they need to be and directing the browser at the correct location. Currently all development is done on a network-drive which is also the test-server. The test-server is only available when inside the the local network (can be accessed trough vpn), and is available on the address 'site.test' in the browser (requires editing to the hosts-file on all the clients, but since there are so few of us that hasn't proven to be any problem at all). All development is done in visual studio. Whenever a file is change the developer that changed the file is required to write the file he changed into a word-document and include a small description as of what was changed and why. Then, whenever there's supposed to be a version-bump (deployment), our lead-developer goes trough the word-document and copies every file (file by file) that has changed over to the production-server. Now, I don't think I need to tell you that this method is very error prone (a developer might for instance forget to add that he changed some dependency, and that might cause problems when deployed), and there's a lot of work involved with deploying.
And here comes the main question. I've been asked by the lead developer to use some time and see if I can come up with a simple solution that can simplify and automate the "version-control" and the deployment. Now, the important thing is that it's as easy as posible to use for the developers. Two of the existing developers have worked with computers for a long time, and are pretty stuck up in their routines, so for instance changing it into something like git bash wouldn't work at all. Don't get me wrong, I love git, but the first time one of them got a merge-conflict they wouldn't know what to do at all. Also, it would be ideal to change to a more distributed development-process where the developers wouldn't need to be logged into vpn (or need internet at all) to develop, and the changes they made offline could be synced up when they were done with them. Now, I've looked at Teem Development Server from Microsoft because of it's strong integration with Visual Studio. As far as I've tested it seems possible to make Visual Studio prompt the user if they want to check in changes whenever the user closes Visual Studio. Now, using TFS for source-control would probably eliminate most of the problems with the development, but how about deployment? Not to mention versioning? As far as I've understood (I've only looked briefly at TFS), TFS has a running number for every check-in, but is it possible to tell TFS that this check-in should be version 2.0.1 of the system (for example), and then have it deploy it to the web-server? And another problem, the whole solution consists of about 10 directories with hundreds of files in, though the system itself (without images and such) is only 5 directories, and only these 5 should be deployed to the server, is this possible to automate?
I know there's a lot of questions here, but what is most important is that I want to automate the development process (not the coding, but the managing of the code), and the deployment process, and I want to make it as simple as possible to use. I don't care if the setup is a bit of work, cause I got enough time at hand to setup whatever system that fits our needs, but the other devs should not have to do a lot of setup. If all of the machines that should use the system needs to be setup once, that's no problem at all, cause I can do that, but there shouldn't bee any need to do config and setups as we go.
Now, do any of you have any suggestions to what systems to use/how to use them, in order to simplify the described processes above? I've worked with several types of scm-systems before (GIT, HG and SubVersion), but I don't have any experience with build-systems at all (if that is needed). Articles, and discussion on how to efficiently setup systems like this would be greatly appreciated. In advance, thanks.
This is pretty subjective territory, but I think you need to get some easy wins first. The developers who are "stuck up in there ways" are the main roadblock here. They are going to see change as disruptive and not worth it. You need to slowly and carefully go for the easy wins.
First, TFS is probably not going to be a good choice. It's expensive, heavy, and the source control in TFS is pretty lousy. Go for Subversion: it's easy to setup and easy to use, and it's free. Get that in place first, and get the devs using it. Much easier said than done.
Later (possibly much later), once the devs are using it and couldn't imagine life without a VCS, then you could switch to Hg or Git if you need first class branching and all those other nice features.
Once you have Subversion in place, you can use something like JetBrains TeamCity or Jenkins, both of which are free and easy to use. However, I'm just assuming you don't have a lot of tests and build scripts that the CI server is really going to be running, so it's far more important that you get VCS first. In all things: keep it as simple as possible. Baby steps. Get some wins, build trust, repeat.
I can't even begin to think where to begin with this! Intending no offense directed at you, apart from the mention of git and HG, this post could have been written 10 years ago.
1) Source control - How can a team of developers possibly work effectively without some form of source control? Hell, even if it's Visual Source Safe (* shudder *) at least it would be something. You have to insist that the team implement source control. You know what's available so I won't get into preaching about that. (However, Subversion with TortoiseSVN has worked quite well for me.)
2)
"write the file he changed into a
word-document and include a small
description as of what was changed and
why"
You have got to be kidding... What happens if two developers change the same file? Does the lead then have to manually merge two changes that s/he extracts from the word doc? Please see #1 and explain to them how commit comments work.
Since your don't really need to "build" (i.e. compiled, etc.) anything, you should be able to solve most of your problems with some simple tools. First and foremost you need to use a source control solution. Yes, the developers would have to learn how to use another tool (EEEK!). You could do the initial leg work of getting the code into the repository. If you have file access to the other developers machines, you could even copy a checked-out working copy to their machines so they wouldn't have to do the checkout themselves (not really that hard). You could then use all the creamy goodness of version control to create version branches when each deployment needs to be done. You could write simple scripts using the command line SVN tools to check out said branches and automatically copy the files to the target server(s). Using a tool like BeyondCompare, the copy process could be restricted to only the files that are different (plus BC can handle an FTP target if that is an issue). By enforcing commit comments on the SVN repo, you'll guarantee that the developers provide comments, and for each set of changes between releases you could very easily generate a list of all those comments using the CSM log retrieval features.
If I want to enable a new piece of functionality to a subset of known users first, is there any automated system of framework that exists to do this?
Perhaps not directly with version control - you might be interested to read how flickr goes about selectively deploying functionality: http://code.flickr.com/blog/page/2/
And this guy talks about implementing something similar in a rails app: http://www.alandelevie.com/2010/05/19/feature-flippers-with-rails/
Most programming languages have if statements.
I don't know what "switching between them at runtime" means. You usually don't check executable code into an SCM system. There's a separate process to check out, build, package, and deploy. That's the province of continuous integration and automated builds in agile techniques.
SCM systems like Subversion allow you to have tags and branches for parallel development. You're always free to build, package, and deploy those as you see fit.
As far as I know no...
If you wanted a revision control system that had multiple versions that you could switch between. Find a SCM you like and lookup branching.
But, it sounds like you want it to me able to switch versions in the SCM programmatically during runtime. The problem with that is, for a revision control system to be able to do that it would have to be aware of the language and how it's implemented.
It would have to know how load and run the next version. For example, if it was C code it would have to dynamically compile and run it on the fly. If it was PHP it would have to magically load the script in a sandbox http server that has PHP support. Etc... In which case, it isn't possible.
You can write an app to change the version in the scm by using the command line.
To do it during runtime, that functionality has to be part of the application itself.
The best (only) way I can think of doing it is to have one common piece of code that acts like a 'bootloader', which uses a system call to checkout the correct branch based on whatever your requirements are. It then (if necessary) compiles that code, and runs it.
It's not technically 'at runtime', but it appears that way if it works.
Your first other option is something that dynamically loads code, but that's very language-dependent, and you'd need to specify.
The other is to permanently have both in the working codebase (which doubles your size if it's a full duplication), and switch at runtime. You can save a good bit of space by using objects that are shared between both branches, and things like conditional compilation to use the same source files for both targets.
What is the best version control system to implement with PowerBuilder 11.5?
If you have examples of how you have did branching/trunk/tags that would be awesome. We have tried to wrap our heads around it a few times and always run into problems because we use shared libraries such as PFC/PFE in multiple applications.
Right now we are only using PBNative, and it sucks.
The Agent SVN is a MS-SCCI Subversion plug-in works with PowerBuilder.
Here is a link that describes how to setup Agent SVN to work with PowerBuilder and Subversion.
We currently use Perforce and it's P4SCC plugin, which works very well. In fact, I'm sure I read somewhere that the guys at Sybase who write PowerBuilder, actually use Perforce themselves.
So, to be fair, let's start out by saying that while you're asking about version control, PBNative is source control. If you compare something that is intended to have more features than just keep two developers from editing the same piece of source, then yes, PBNative will suck. The Madone SL may be an incredible bicycle, but if you're trying to take a couple of laps around an Indy track, it will suck.
"Best" is a pretty subjective word. There are lots of features available in version control and configuration management tools. You can get tons of features, but you'll pay through the nose. StarTeam has some nice features like being able to trace a client change request or bug report all the way through to the changed code, and being able to link in a customized diff tool (which is particularly useful in PB). Then again, if cost is your key criteria rather than features, there are lots of free options that will get the job done. As long as the tool supports the Microsoft SCC interface, you should be OK.
There is a relatively active NNTP newsgroup that focuses on source control with PowerBuilder, which you can also access via the web. You can probably find some already-posted opinions there.
Many years ago I used Starteam to control PB applications. PowerBuilder needless to say is an outdated bear, and it has to export each and every object from its "libraries" into source control.
Currently our legacy PB apps have its libraries saved whole into Subversion, without any support for diff's etc.
We use Visual SourceSafe. We don't use PFC, but we do have libraries that are shared among several projects. Till now, each project was developed separately from the others, and so the shared libraries were duplicated. To have them synchronized, they were all shared at the VSS level. Lately we've reorganized our sources so all projects are near each other, and there's only one instance of the shared libraries.
VSS is definitively not the best source control system, to say the least, but it integrates into PB without the need of any bridges. PB has an inherent problem working with source control, so it probably won't make a very difference working with one instead of the other (at least from the PB point of view).
Now, on a personal note, I'd like to say PB 11.5 is a piece of sh*t. It constantly crashes, full of unbelievable UI nuisance and just brings productivity to its knees. It's probably the worst IDE ever created. Stay away if possible.
FYI: The new PB12 (PB.NET) will integrate with SCC systems so you can easily choose which source control system that you want to use. Since we basically have dropped PBLs (they are now directories) files can be checked in/out individually - even with a plain vanilla editor since files are now normal (unicode) text files.
StarTeam integrates so beautifully with the PB IDE. I used that combination at my previous company (PB9 and ST5.x) for several years. You should be managing your code at the object level - don't log the entire PBL into ST...
If you're having problems with that setup, hit me up offline. phoran at sybase dot com.
We use Merant Version Manager for older projects and TFS for newer work. The only issue we have is that TFS does not support keyword expansion and changing the 'read the flowerbox comments' attitude people have. Some folks are nervous about losing the inline versioning history.
We use StarTeam and have been very pleased with it. It combines bug tracking with version control. Unfortunately though we don't store our files on the object level. We just store the PBL files directly in source control. Anything that supports the SCC interface theoretically should work correctly in PowerBuilder.
PB9: We used PVCS but had stability problems with pbl corruption and also problems co-existing with later versions of Crystal Reports (dll conflict) so now we use PB9 with Dynamsoft's Source Anywhere Standalone. This system is more primitive; it is missing the more advanced features for promotion levels and for pulling out an older milestone version of all objects to make a patch build.
What we are looking for now is something which will allow more advanced "change management", to support promotion levels at the change level (rather than at the object level). Would it be better to use perforce, starteam, or (harvest change manager + HarPB), or something else? Any advice on these combinations would be greatly appreciated.
You can always use Plastic SCM with PowerBuilder through SCC. Plastic is pretty advanced in terms of graphics, tools, replica and so on, so it's always a good choice to keep in mind.
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system