I am using Talend Open Studio for Data Integration.
I am looking for a way to use versioning for our project.
Does Talend Repository able to do it?
What is the benefit of using repository?
You can do versionning for your project in talend.
And Moreover you can do a versionning for each job.
File -> project parameter -> general -> version (for all project version)
In the property of job (for unique job version upgrade)
Moreover you can use a SVN in the paid version of talend (not the Talend open Studio).
This SVN allow you to work together on a same project.
When a people work on a job the job is locked and the other people can only see it, not modify it.
You need to unlock the job or to ask people to close it to modify.
You can upgrade the version of job when you want in the property of the job.
EDIT :
If you want to work with a team with the free version you can't use default SVN.
You need to import/export job. It's little bit bad but with a little adaptation. You can use the versioning of job.
I have listen that some company develop their own SVN.
Related
For our ERP platform (NetSuite) customization code rests in the Cloud. We (different entities) can directly make changes to it but there is no source control available to us in cloud.
It is possible to fetch the code files through a SOAP API.
I was wondering if it is possible to get the files through API using Apache ANT and shove into TFS/SVN?
I am not familiar with Apache ANT so I do not know the capabilities of ANT that if it can fetch any info through API?
(you can also suggest any better approach to source control the code in cloud)
Ant has several third party task plugins for version control tasks. Plus, you can always use the <exec/> task to build an equivalent command line checkout. However, I do not recommend people use Ant to fetch versions from your version control system. This ends up being a chicken v. egg issue.
Your build script is in version control. You need to fetch it in order to run Ant against it. If you're fetching your build script, why not the rest of your project?
Once you checked out your project in a working directory, and want to do an update, why not let Ant do the update? Because your build script is also version controlled. Doing an update and build at the same time could have you running the wrong version of your build script against your build.
Maybe you're going to check in the files that were modified by the build system. Not a good idea. You should rarely, if ever, check in files you built. If you need them, rebuild them. Built files are usually binary in nature, and can vary greatly from one version to another. In most cases, your version control system will be checking in completely new versions of the built object instead of using diff format. That takes up a lot of room in your version control system.
Even worse, you can't diff the built objects, so you can't really verify their content or trace their history. And, built objects tend to age very quickly. Something built last month is already obsolete. With in a year, the vast majority of the information in your version control system will be nothing but obsolete binary, and very little stored is useful code.
Besides, your version control system has nothing to do with building your files. Imagine between Release 2.1 and Release 2.2, you change version control systems from Subversion to Git. Now, a bug in Release 2.1 needs to be fixed, and you need to create Release 2.1.1. Your checkout code in your build scripts will no longer work.
If you're using NetSuite IDE, you're using Eclipse, and Eclipse is great at handling version control. Eclipse can handle both SVN and TFS (although I don't know why anyone would use TFS). Eclipse tracks file changes quite nicely. In fact, Eclipse gets confused when you change files behind its back (like you do an update outside of Eclipse).
Let Eclipse handle your version control issues. It presents a common interface to almost all version control systems. This way, your build system can handle the builds.
I'm not sure what other requirements you might have, but if you use the NetSuite IDE (Eclipse + bundled plugin), you can use it to pull and push files to NetSuite. And then you can use any source control system you like (we use SVN, for instance).
I want a version control system tool, but offline.Like I develop a project on my computer,and someone is working on a different part of this project on a different computer.Is there a tool that allows to me bring the project from different computer to mine and sync all the changes.
I would like to have all functionalities of a version control system like diff,rollback,commit
Please suggest a suitable tool.
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
http://git-scm.com
It can be used online or offline easily.
Almost all the version control tools on the market support these features: diff, rollback, commit, offline, etc. I list some tools here for your reference:
Open Source
Git
SVN
Commercial
SourceAnywhere (developed by the company I'm working for)
Microsoft Team Foundation Server
I thought I heard that there was going to be a entry level, low cost version of TFS that is targeted at VSS users who want repository and versioning functionality only. But I can't find the link anymore...does it exist? Or do I need to figure out how to use subversion?
You're looking for TFS Basic, an installation option in TFS.
It starts at $500.
I would recommend SVN. Go here for TortoiseSVN, an integrated windows shell solution. Alternatively, you could use VisualSVN or any number of other SVN clients, some with VS integration. If you understand the basics of versioning and source control, Tortoise is perfect for you - it's all GUI so you don't need to mess with a CLI unless you want to.
I'm looking for a version control system just for me on my windows computer to integrate into eclipse. I was thinking to use Mercurial instead of Subversion, but I'm having doubts about the mercurial eclipse plugin. Any input on this that you can help me with?
Is it worth it to have a version control system when you're working alone, how much is it going to complicate matters? I don't think I need a remote repository since it's just for me. And what is known to work well in eclipse?
Is it worth having a version control system for just yourself ? Absolutely. Why ?
You can retrieve old versions of code - for reference, to revert changes.
you can branch and tag to create different versions and checkpoint for releases.
Your continuous integration system (you do have one, don't you?) can tag successful builds, allowing you to identify particular intermediate builds.
You can record in the logs why you've changed stuff (as opposed to what you've changed), and meta-information surrounding those changes.
So version control isn't used to manage multiple developers, but rather to manage the codebase itself.
What works well in Eclipse ? I can vouch for Subversion. I've used that successfully for a couple of years. I'm not sure I'd use a distributed system like Mercurial, unless I was in the habit of (say) developing on a laptop on the move, and on a desktop at home.
I have used the Subclipse plugin for SVN and it worked like a charm. In regards to whether or not you need a version control system while working alone, it's still a good idea. It will save your version history and allow for easy rollbacks. Also, if you ever bring on another person to the project it will be easy to get them up and going.
Is it worth it to have a version control system when you're working alone
Yes of course, you will always run in cases like, the application was running yesterday but i dont know what i did!
how much is it going to complicate matters?
It will not complicate anything, you will just need to spend half an hour at the beginning to set it, then committing,branching, uploading, sharing will all be one click away in Eclipse.
I don't think I need a remote repository since it's just for me.
I work alone as well, but you never know, if you might work on different sites it would be good to have all your work in the cloud, sometimes you run in cases like you want to share a project with a friend and whats better than SVN in that case.
And what is known to work well in eclipse?
I use Subversion, inside Eclipse and TortoiseSVN in the explorer.
If you want to setup your own SVN Server, (with the benefit of not needing to upload/download from internet each time) check here:
Create SVN Server on Windows
Create SVN Server on Mac
It IS important to have a SCM system even when working alone.
I'd suggest creating a project in code.google.com or sf.net, (unless of course you don't want an open source license).
Eclipse has built-in "Local history", you can check if it is sufficient for your needs. Otherwise you can simply install an SVN server from Collab.net, and use it on localhost with Subclipse
There is also a git plugin for eclipse. only problem is merge not being integrated yet. but is planned for the near future.
egit
The Mercurial plugin for Eclipse seems to work fine. I don't think it has all of the features that Subclipse has for Subversion though.
If you are working alone on a project though, you need to ask yourself why you are using a distributed version control system. For a project by yourself, Subversion works great. I use subversion and the eclipse project for projects I work on by myself. It gives you the history and rollback capabilities even with a single person. It is nice sometimes to be able to see what you did before that you might have deleted.
In a team environment though, the Mercurial plugin for Eclipse works fine.
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 2 years ago.
Improve this question
How do you manage your project life cycle?
For example: Do you start with a template? Do you use versioning such as SVN as the authoritative source? Do you archive the projects, if so when and how? When a project is revived (work resumes), how’s that handled? Do you use automated scripts to do things such as create IIS sites, DBs, archive, launch, etc?
Of particular interest is management of many projects at varying points of development.
Development: We do not start with a template, because the world changes quick enough to make template maintenance a full time job. We do encourage everybody to use the same IDE (Eclipse), so that they can help eachother with their environments.
Project Management: We are using GForge to manage our projects. Sourceforge is slightly better, but GForge is much cheaper and has a different licensing fee model. GForge incorporates CVS, SVN, Document storage, Issue trackers and integrates everything nicely. This makes it easy to see where the project is at. Open issues, and closed issues with connected code changes, everything is integrated.
Versioning: Although we tried SVN, we switched back to CVS because it fits our needs better and works fine.
Backups: Our GForge server, housing all our projects and sourcecode, is running on a VMWare EX server. Backups are done daily on VM level and we make VM snapshots if we feel that we need more frequent restore points for some reason.
Reviving projects: This is very common in our business. Every project has all it's libraries and build requirements in CVS. The project always has an up-to-date development manual which describes all the steps to get a development environment running, and has a chapter with all the things which are not default, to pay attention to. We try to build software in an as-default-as-possible environment so that developers don't have to spend days tweaking their settings.
Nearly all projects are built using Maven, which also makes life easy for our developers. Ususally reviving a projects only takes a few steps:
Download eclipse
Connect to CVS over SSH (extssh is built into Eclipse)
Check out the project (default "Check Out" option)
Run "Maven Eclipse" and refresh Eclipse
Run unittests in Eclipse to see if everything is working.
Builds: All our projects are built on a seperate build server. Every morning the build server does a complete build and tags CVS if all unittests succeed. During the day, hourly builds are made and when there are failures the team automatically gets an email. Usually we use one build server per project, and it is a simple luntbuid server (Linux, Tomcat, Luntbuild).
Both the buildserver and sometimes even the developer machines are VM's. This makes reviving a project really easy. Get the VM from the fileserver, start it up, and you're good to go.
The build server creates daily sites which show unittest coverage statistics, complexity measurements, CVS activity and developer activity (who changed what and when).
All our software comes with self-building database scripts built in. Point the config file to the database, start the software, and it figures out what it needs to do to the database itself. This really comes in handy because the buildserver can just start the software. No special steps needed. Our customers are also happy, they never need to worry about their database, or upgrade scripts.
The whole project lifecycle is managed, documented and tracked in GForge, with the addition of some external spreadsheets for budget tracking because that's simply easier.
Wether you have an integrated project server or not, I think it is really important to have a system. This enables you to switch developers between projects without them getting lost. It saves time. Particularly when a customer comes back to you after 2 or 3 years for modifications on old software (yes, that happens).
All the stuff we use is open source (you can even use an open source fork of GForge). It's not in the tools, it's how you use them.
It would depend on the nature of the work. When working at home for private clients, I start by opening a folder for the client with a bunch of standard documents, which I customize, such as contracts, invoices, reports, requirements, testing, code repository, etc. As the project develops, I add/modify the directory as required.
If I had to go back to a project, I would reopen that directory, and for any non-common components, create a new directory. For example, if my client had a web application built, and now they need a second application, I would use the same directories for invoices and contracts and create new directories for the code base, requirements and testing.
In terms of backup, I archive the work at any point where I've reached a milestone, with the exception of code, which I back up daily at a minimum. At the end of each project, when I close a contract, I take the entire directory and compress it and store it on a remote server.
i create folders containning the project stages like "initialize software process" on were we placed docs like the bussiness proposal, we use another one for requirements another for the construction,releases,one for meetings minutes, and so on.
We keep those under a subversion repository but it really depends on what metodology you are using, also it depends on how do you handle the configuration management and how organize you want to be. and yes we use template for most of our artifacts so we assure in some way the quality of our products.
As for source code, we have it all in a Subversion repository. After each release, we make a branch - new features only get added to the current branch (on which the next release will be based), critical bug fixes are done in the current and the old branch (so we can deliver hotfixes for the version the customers currently have).
As for all documents belonging to a release - from the planning & resource sheets to specifications, testcases, user and technical manuals for the software we create etc. - we store them in a Sharepoint portal site. The advantages of this Sharepoint site is that users have access via a website (so no need to grant management access to your repository ;-), you can finely control the access rights, and you can turn on versioning. We also use tagging to mark whether a document belongs to a specific release (e.g. service pack xy) or product, or whether it is generally valid.
Concerning scripts, we use several to perform e.g. nightly build plus unit tests (we usually do that for the last and the current release), but also to deploy the complete software solution (including IIS site creation, database data model upgrade,...) on out test servers. These are nant scripts using lots of variables for paths, version numbers etc. so it is very easy to copy and modify them for a new release.