I'm new to stack overflow.
I learnt visual basic 6.0 on my own(with the help of the internet) And i migrated to vb2010 and next to vb 2012.now my question is how to work in a team with my friend(s) in a same project(without spending any extra money exept the internet cost(my father wont give me money)).my friend is in a distant place.
can anyone help me to solve this problem.
anyone who can help me are appreciated.
I would start with a good version control system, I would recommend a GIT e.g.: http://git-scm.com
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.
Git is easy to learn and has a tiny footprint with lightning fast
performance. It outclasses SCM tools like Subversion, CVS, Perforce,
and ClearCase with features like cheap local branching, convenient
staging areas, and multiple workflows.
Alternative you can use SVN as well, here the comparison of both systems: https://git.wiki.kernel.org/index.php/GitSvnComparison
Git is much faster than Subversion Subversion allows you to check out
just a subtree of a repository; Git requires you to clone the entire
repository (including history) and create a working copy that mirrors
at least a subset of the items under version control. Git's
repositories are much smaller than Subversions (for the Mozilla
project, 30x smaller) Git was designed to be fully distributed from
the start, allowing each developer to have full local control Git
branches are simpler and less resource heavy than Subversion's Git
branches carry their entire history Merging in Git does not require
you to remember the revision you merged from (this benefit was
obviated with the release of Subversion 1.5) Git provides better
auditing of branch and merge events Git's repo file formats are
simple, so repair is easy and corruption is rare. Backing up
Subversion repositories centrally is potentially simpler - since you
can choose to distributed folders within a repo in git Git repository
clones act as full repository backups Subversion's UI is more mature
than Git's Walking through versions is simpler in Subversion because
it uses sequential revision numbers (1,2,3,..); Git uses unpredictable
SHA-1 hashes. Walking backwards in Git is easy using the "^" syntax,
but there is no easy way to walk forward.
Related
I have been tasked with setting up some type of version control for our development server files location. We current use Oracle's Service Cloud called "Right Now". It holds our dev/staging/prod environments for multiple sites.
Basically I need to VC just the dev files.. and not have to carry a local repo. Is this possible? The reason being for no local is there are just tooo many sites to download all locally. I want to open the files in Sublime from the dev server, make changes, save them, then at some point create a commit regarding the files I changed since the last commit. How can this be done.
I would love to use git, but this requires a local repo as far as I can tell. What about SVN? Could this do it? Your suggestions and resource links are appreciated.
~ WB
Unfortunately I'm not familiar with Oracle's "Right Now" product so I may be missing something important here. Putting this "Right Now" aside, I can say that Apache Subversion can be a good match for your requirements.
With Subversion you don't need to download the whole repository as you need with Git. Subversion's working copy which you need to svn checkout is much less in size than the whole repository in Git because is represents a particular snapshot of the repository's state in time (it does not contain the whole repo history as in Git).
You can checkout only a part of a repository. E.g. if a repository contains multiple projects, you can choose which ones to checkout.
Using sparse directories / shallow checkouts can help you to minimize the size of the working copy by specifying only those modules you require to operate on.
I am new to git and while I can see the immense benefits of the branch/merge process on individual projects, it also seems to me that another useful application of Git is to use it for centralizing the core custom code and templates that you often use in all your projects, with each project starting off as its own branch.
For example I have a large set of custom code that is just a starting place that I use for all apps. If I tweak it here and there, or find bugs and fix them, I want that to replicate through all projects that use the code.
By working on tweaks in a separate branch off the master, then merging back to the master, and then merging the master with other branches that occupy separate projects, it would seem I can achieve this quite well.
Are there any major drawbacks to this approach to Git?
Also while I know that submodules exist, I prefer not to use them at this time since they are not natively supported in Xcode.
Several projects will tend to advance on their own terms. If you have all together on the same branch, you see intermingled commits, and there isn't any sense of history to be discerned. If you place each project on a separate branch, you'll have to jump from one to the other, and there won't be any advantage against separate git repositories (git is very lightweight!).
A DVCS does add overhead (if there are several repositories with the same contents, it certainly adds disk space; but that is dirt cheap nowadays...). It has the advantage that you can work anywhere, freely (no need to wait for a slow connection), and (at least with git) the operations are normally so fast that until you get used to it you have this lingering fear that you are being cheated and nothing has been done...
For development, the fact that branching and merging works and is cheap means experiments and exploration are encouraged. The fact that commits are instantaneous and use up very little space leads to microcommits (one logical change, even a minimal bugfix or typo, per commit), instead of "a morning worth of work" dumps. This makes history understandable, and tools like git bisect extremely useful.
I have a bunch of git repositories with stuff I want to preserve history on, but not necessarily ever share with anybody else. Some more important of that stuff I keep also in remote repositories (not much more than git and ssh at the other end, and a bit of discipline to push there now and then, are required) for backup. In that sense, I use git more as a local VCS, which also has the advantage that I can share with others ;-)
I have what I hope is not a unique situation...
...and I'm looking for suggestions.
I am looking for a better synchronization plugin for Eclipse than FileSync
-or-
I am looking for a distributed (preferably) version control system that will allow me and the other developers in my team the ability to work with local files and have that repository automatically upload changes and revision history to our development box
-or-
A combination of the two.
Most revision control applications I've tried are catered more to the compiled code workflow where you only check in when you have a compilable code base, and that makes sense to me. We, however, are working with Coldfusion pages on a remote development server which complicates the process of check-ins, quick updates and debugging. Now, I don't necessarily want to have to check in every time I want to test code (because that would be a nightmare...) but it would be nice to have something that tracks changes throughout the day and logs those changes in a revision control automatically (Dev would state intention in dialog on opening the project?) while keeping the files on the development server in sync with all the programmer's machines. It would be awesome if it tracked changes locally and did one auto check-in per day (at some scheduled time, preferably as a background process), but I've not seen anything like this.
Currently we are shoe-horned into using Serena PVCS (because they have free licenses mainly) and it's not a very fast solution when we all work in different States, our development server is in a State that none of us work in, and the repository is in an even different State. (No control over this!) It normally takes Eclipse 10-15 minutes to synchronize ~500 files with the PVCS server and check-ins are "Eclipse-lockingly" slow. (ie: when checking in, forget using Eclipse for anything.)
I would like to have a workflow process that manages all our workfiles locally, synchronizes those changes to a remote development server and pulls down any changes that happen to be up there. I do not count on having any/many conflicting merges during this because we all work on different parts of the same site. However, it may happen.
I have played around with Bazaar, and this is what made me think about having a distributed revision system, but I'd like to have that auto-merge with the remote repository (the development server in this case) and I did not find a way to do that when local files were updated. I will have to admit I have not looked into Git or Mercurial much and was hoping that someone could share their experience with me on feature sets or solutions if one of these other options will work.
To give a back history, this came about when one of our developers started using FileSync in Eclipse and started overwriting all our changes because the Eclipse FileSync plugin is only one way... from the dev box to the server. Boss asked why we weren't checking in all the time... we blame the speed... I get tasked to find a solution.
Also, a centralized solution like SVN was already turned down (because we have Serena and a crew of people that are supposed to manage this... but I've been waiting two days for even a response to an issue log I submitted concerning our lack of speed issue, so if we can self manage a solution [thus distributed and why I looked at Bazaar] that would be awesome.)
A DVCS like Git or Mercurial would definitely be a sensible choice, especially for:
distributed development
distributed repos (including one dedicated for those checks of yours)
That notion of dedicated repo is not a new one and has been used before (for local repo used for testing before pushing to a remote repo), but it can easily be adapted for the kind of automatic pushing you are looking for.
For a strong Eclipse integration, I would go with Git (even though EGit is not fully baked yet): all Eclipse projects (for the development of Eclipse) itself are or will be soon on git repo.
Eclipse is committed to replace its current native CVS integration with a complete native Git integration.
We're considering a switch from SVN to a distributed VCS at my workplace.
I'm familiar with all the reasons for wanting to use a DVCS for day-to-day development: local version control, easier branching and merging, etc., but I haven't seen that much that's compelling in terms of managing software releases. Here's our release process:
Discover what changes are available for merging.
Run a query to find the defects/tickets associated with these changes.
Filter out changes associated with "open" tickets. In our environment, tickets must be in a closed state in order to merged with a release branch.
Filter out changes we don't want in the release branch. We are very conservative when it comes to merging changes. If a change isn't absolutely necessary, it doesn't get merged.
Merge available changes, preferably in chronological order. We group changes together if they're associated with the same ticket.
Block unwanted changes from the release branch (svnmerge block) so we don't have to deal with them again.
Sometimes we can be juggling 3-5 different milestones at a time. Some milestones have very different constraints, and the block list can get quite long.
I've been messing around with git, mercurial and plastic, and as far as I can tell none of them address this model very well. It seems like they would work very well when you have only one product you're releasing, but I can't imagine using them for juggling multiple, very different products from the same codebase.
For example, cherry-picking seems to be an afterthought in mercurial. (You have to use the 'transplant' extension, which is disabled by default). After you cherry-pick a change into a branch it still shows up as an available integration. Cherry-picking breaks the mercurial way of working.
DVCS seems to be better suited for feature branches. There's no need for cherry-picking if you merge directly from a feature branch to trunk and the release branch. But who wants to do all that merging all the time? And how do you query for what's available to merge? And how do you make sure all the changes in a feature branch belong together? It sounds like total chaos.
I'm torn because the coder in me wants DVCS for day-to-day work. I really want it. But I fear the day when I have to put the release manager hat and sort out what needs to be merged and what doesn't. I want to write code, I don't want to be a merge monkey.
You really want to be using git in this situation, because it is so vastly superior when it comes to merging and release management. Git allows for a signoff process for changes to go to release; it actually provides support for multiple layers of release management, precisely because that is how Linux is managed.
Simply put each release in a branch. Instead of blocking out changes you don't want, accept only those that you do, by only signing off for release those changes that are going into a release.
Git also allows you to cherry-pick a collection of changes into a single patch to be sent upstream, so you don't have to carry all the 'oops, that didn't quite work' patches into the release branch or repository, only nice clean feature or fix patches.
Just moved to subversion...from visual studio. I love it already! Can someone briefly explain
Repository
Branches
Tags
Trunk
Do I need to create a new repository for every project? Or a new trunk?
Thanks
You don't need a separate repository, but you can if you want. I recommend reading the book at http://svnbook.red-bean.com/. Grab the pdf version or whatever. It doesn't take too long, and it explains some things pretty well. I read it, and found that I'm glad I did.
Remember that subversion is just a fancy filesystem that supports versioning. Think of a repository as a "drive root" like "C:/".
Each project gets a trunk, tags and branches directory. All of your day to day work happens in the trunk. Experimental code is done in a branch and then merged back into the trunk at a later date. Tags are for when you release the software. These are not to be edited. When you release the software, you create a tag with a unique name based on what is currently in the trunk.
I can't say whether or not you need a separate repository for each project, there are pros and cons. This blog posting details them:
Simplified administration. One set of hooks to deploy. One repository
to backup. etc.
Branch/tag flexibility. With the code all in one repository it makes it
easier to create a branch or tag
involving multiple projects.
Move code easily. Perhaps you want to take a section of code from
one project and use it in another, or
turn it into a library for several
projects. It is easy to move the code
within the same repository and retain
the history of the code in the
process.
Here are some of the drawbacks to the
single repository approach, advantages
to the multiple repository approach.
Size. It might be easier to deal with many smaller repositories than
one large one. For example, if you
retire a project you can just archive
the repository to media and remove it
from the disk and free up the storage.
Maybe you need to dump/load a
repository for some reason, such as to
take advantage of a new Subversion
feature. This is easier to do and with
less impact if it is a smaller
repository. Even if you eventually
want to do it to all of your
repositories, it will have less impact
to do them one at a time, assuming
there is not a pressing need to do
them all at once.
Global revision number. Even though this should not be an issue,
some people perceive it to be one and
do not like to see the revision number
advance on the repository and for
inactive projects to have large gaps
in their revision history.
Access control. While Subversion's authz mechanism allows
you to restrict access as needed to
parts of the repository, it is still
easier to do this at the repository
level. If you have a project that only
a select few individuals should
access, this is easier to do with a
single repository for that project.
Administrative flexibility. If you have multiple repositories, then
it is easier to implement different
hook scripts based on the needs of the
repository/projects. If you want
uniform hook scripts, then a single
repository might be better, but if
each project wants its own commit
email style then it is easier to have
those projects in separate
repositories
I agree, read the svnbook. It's a great resource.
Do I need to create a new repository for every project? Or a new trunk?
Kevin covered the single/multiple repository trade-offs pretty well. When we started with svn, we used one repository for all of our development projects. It worked well and had all the advantages mentioned. However, as the repository got bigger it got more difficult to administer because of the size of the dump file and resulting issues during backup. It also became an issue that projects couldn't easily be archived out of the repository - it's certainly possible but it requires dumping and pulling out projects from the repository. They aren't issues you can't get around but it's something to keep in mind.
Repository
Branches
Tags
Trunk
Branches, tags and the trunk are just copies of your files contained in the repository. It allows you to segregate and check-mark your files at whatever time you feel appropriate (usually at a release or a feature branch).
An important thing to keep in mind about branches, tags and trunk is that they just conventions in svn. There is no functional difference between the three locations, they are just an accepted usage model and they can be changed or organized differently if you have a good reason. I'm not recommending that you organize differently but you'll find that svn is very flexible because there isn't really a forced organizational structure other than convention.
Depending on how many projects you decide to have in your repository, you may organize differently.
You can have the subdirectories with projects under it:
\repo
\branches
\...
\tags
\...
\trunk
\..
or you can have projects contain the subdirectories:
\repo
\Project1
\branches
\tags
\trunk
\Project2
\branches
\tags
\trunk
There are trade-offs that are covered in the svnbook. The first method is usually used if you only have one project per repository and the second if there is more than one project in your repository.
The nice thing is that you can just start using svn and then figure out what you prefer. You should have some sort of organization but, with cheap copies, you can always re-arrange the folders as your situation or workflow changes.
An important thing to remember with SVN, compared to other version control systems like CVS or Git, is that SVN doesn't really have a concept or branching or tagging. As far as SVN is concerned it's all just a bunch of folders and files. So while you'll see a lot of people using the branches/tags/trunk setup, this is not required and you are able to deviate from this if you so choose.
Generally speaking 'trunk' is where you keep your active development going. So this is where you do all your commits. Whether or not you checkout trunk or use tags/branches instead is entirely up to you.
Branches, as I've used them, are usually for when you need to do large changes to your application but don't want them in trunk because you want to be able to continue developing against trunk without deploying your other changes. In this case you may have something like
\repo
\trunk
\branches
\version_two
In this case you can develop in both trunk and version_two separately and, assuming your live site is a checkout of trunk, you don't need to worry about 'accidentally' breaking your live site with your other changes. And when those changes are done and ready you just merge them back into trunk whenever you want.
Tags can be used similarly to branches, in that instead of checking out trunk and just using 'svn up' to update your repository you instead of several tags, each representing one release. So your repo may look something like
/repo
/trunk
/branch
/version_one
/version_two
/tags
/1.0.0
/1.0.1
/1.1.0
In this case the general idea is that when you're ready to do a deploy you do an
svn copy
To copy trunk over to a tag (in this case the next one could be 1.1.1, 1.2.0, 2.0.0, etc). How you name your tags it entirely up to you though and, again, depends on your project and requirements. With this route instead of doing a regular 'svn up' you would have to do an svn switch. So you have to deploy with
svn switch https://svn.yourrepo.com/repo/tags/1.1.0
The switch will automatically do updates, adds and deletes on the appropriate files.
When it comes to one repo for many projects or separate repos for each one I am an advocate of one repo per project. It provides the additional benefits of easily managing access to it. But most importantly it means that each project has a separate commit history and separate logs. This m
Reading your tags I see you started using VisualSVN instead of your old VSS system. (Your question says you stopped using Visual Studio.. which makes VisualSVN a strange choice).
One of the major differences between SourceSafe and VSS is that you can choose different tools to access the same repository (and you can switch every time you like as they all share the same workingcopy).
E.g.:
TortoiseSVN for Explorer integration.
The normal subversion client for scripts.
VisualSVN as Visual Studio frontend for TortoiseSVN
AnkhSVN as real SCC (VAPI) package in Visual Studio.