I'm doing a single developer Visual Studio solution and reached a point where I'd like to incorporate Versioning Control. Several posts address this issue, but one problem I'm facing is a large merge. I have a production copy of the solution and a beta copy. They are NOT dramatically different, but they will require a number of interactions I suspect. I'm using TortoiseSVN and have imported the production version.
Yes, I know I should have used Version Control from the start, but that is hind sight. Would it be best practice to simply use the beta as a reference and work the interations from scratch. Or should I branch off and import the beta separately, then attempt to merge the change. Or is there another alternative I'm missing.
Thanks,
dgp
well, I have experienced SVN in the past ... and I must say, it's lovely cause it's really easy to understand the concept, but it's awful terrible when things pass from the plain commit.
I'm currently using GIT (to host small code on GitHub) and Mercurial (Hg) (I use Kiln in the company - was recommended by myself so they can start using - and in BitBucket for personal use)
I have used SVN for more than a hole year and every time I need something from "the past" or to merge something, it was a nightmare, but the server/client concept was really a break deal and extremely easy to get it... but I found my self, over and over to do merging by hand :(
When GIT started to be hot, I was afraid to move as, dang! SVN was a pain, why should be different in a DVCS?
This videos rocked my world, [ part 1 part 2 ], only then I understood DVCS vs VCS and it was with this that I moved COMPLETELY to DVCS and never go back... proudly!
For your problem, I would install git (or hg), and then create a repository on the folder you have your current source with:
git init will tell your folder, "Hey, I'm a GIT Repo"
git add . let's add all files and folders to be tracked by git
git commit -m "initial commit" let's save all the hard work :)
So, now you have a tracked code, you can simple create a branch and overwrite all your files. YES, worry not, you don't need to have copies of your code in a folder called branch ;) no more copies! all is in the GIT database
then, after creating the branch, changed the files, added all files to be tracked on that branch and committed, safely do a merge :)
ohh, and you don't need a server connection to do all this, all you need is a computer with GIT installed... no more connection dependencies! DVCS is cool or what?! :D
Related
I will start by saying this is probably a dumb question so apologies if I am staring at the answer but cannot see.
I have used VCS in the past primarily as a method of allowing me to revert my code if something goes wrong. I have always had a single lime of development. However I get into the usual trouble when releasing and starting the next version - dealing with bugs. So this time I decided to use branching (forking or whatever is the best name). I am a lone developer so I am the only one working with the repositiory. My scenerio is simple. I want to create a branch when I release so that I have a line for the released code and a line for the beta. I can then work happily on the beta. Now a bug comes in and I need to get back to the last commit for the release.
My question is what is the best way to get back that code in the IDE to work on it.
I have read that in Mercurial a simple way is to clone the repository including the working directory. This would give me two copies of the code base and I guess I can choose which one to load into the IDE. I would then use Push or pull to get the bug fixes from the release copy into the beta copy (I think).
I assume there must be another way however without cloning. How would I do that? I can guess at reverting to the last commit of the release code. Then I assume that loading the solution into the IDE would give me that. I am not sure where I would go from there when the code is done.
For the record I looked at a number of different VCS - I have used SVN in the past but wanted to go to a DVCS. I looked at Git, Bazaar, Mercurial and Veracity (and used Code-Coop in the past). You may think another tool would suit my needs better. Having tried the others however I found I could understand the way Mercurial works and the GUI tools such as TortoiseHg with the WorkBench and HgSccPackage (http://visualstudiogallery.msdn.microsoft.com/9bc074fa-9e1f-4ce2-a75d-b90e65f7475a) appeal
There are a lot of good documents and links here Introduction to Mercurial and I have read about different ways to branch that include using bookmarks and so on but they seem primarily targeted at multi member teams - which make sense of course
Many thanks in advance
You are mixing concepts a little, i guess you have SVN background ?
Just to answer you question, to 'get back the code in IDE' you will need to 'update' to a previous version. But this is considering you already have cloned the repository. Is your question about how to clone.. ? As you ask, there is no other way without cloning first. Cloning is the first step towards having a HG repository local. After clone, you can commit and push changes or pull and update.
To expand the answer even further and given that you are going to use Mercurial, here is what you should do:
read this : http://hginit.com/ - great HG (tutorial) by Joel Spolsky him self ! An introduction into HG and the concepts. You will need to understand this very good, since right now you are doing a lot of guessing, assuming and thinking :) HG/Git is different from SVN and in the begging the concepts might be hard to understand and to get used to.
for your project and regarding your question, have a branch called 'dev' or 'trunk' or 'version X' etc where you will commit all new changes.
have a branch called 'live' etc that will represent the current 'live' version. This way, whenever you need to revert back in time to the live version and to do a quick fix on it, you will 'update' to the tip of that 'live' branch, discarding all local changes (after you have committed to trunk! of course).
when putting a version to live, you will need to (assuming all changes are committed !) : update to the live branch then MERGE the version X into local (local being live ). This will include your versionX branch into live - it's what you need at this point. Then, either update back to version X branch or create a new branch - version X+1. This will take care of the versions and keeping the branches separate.
since you are using VS - install http://visualhg.codeplex.com/. HG source control integrated into VS.
I assume there must be another way however without cloning
Yes. You can use (named) branches inside single repo (I prefer HgSccPackage in VS), update to revisionbranch head, change, commit, merge
BTW, branching with bookmarks/clones/branches work the same (good) way for any size of team - it's a matter of taste
I work mainly on a desktop Mac but also have a laptop Mac that I use when away from the office.
I want to access and work on my latest html, css, php and python files from either computer.
I thought Github was the way to do this but am having a problem understanding the "flow" and I've RTFM! I don't understand whether I should create a Repository on Github first, why when I try to "clone" something it doesn't magically end up on my local computer... where the nice big red button that says "sync" is...
... or whether I should just use the commandline ONLY...
So, if I start on my desktop and create new files, what are the correct steps using git or Github (?) to put those files where they can then be accessed from my laptop and then have the files on my laptop merged back into the ?Github repository so I can then access those files from my desktop.
Thank you all for your replies and answers! The git workflow, for my needs, is now clear.
The workflow presented by wadesworld is concise and was the overview I needed.
However, Michael Durrant's commandline steps filled in that workflow specifically with commandline directives - and I needed that also.
steelclaw and uDaY's answers and responses were important because I did not understand that it did not matter which repo I created first and, adding and committing locally were essential first steps in my workflow.
Specifically, steelclaw's response to one of my response questions provided the closure I needed, so I could learn more:
After initializing the repository, be sure to use 'add' and 'commit.' These will make the files an official version of the repository. After that, you need to use 'push' to upload it to the remote repository."
ilollar's resource, "Git for Ages 4 and Up" is also worthy of the click, especially for folks like me who are visual!
Thank you all so very much!!
Do you want to version control your files or just have access to the same files in both places?
It is a good idea to use version control as a developer, whether you're writing code or designing websites. But, to do so, you have to have a commitment to learning how version control systems work, since they all have some learning curve.
But, if you're not interested in that complexity and simply want to be sure you have access to the latest version of your files, then you're looking at a file syncing operation which can be much more simple.
So, which one do you want?
Edit: Based on the response, here's the model:
1) Create repository on work computer.
2) Create repository with same name on github.
3) Push to repository on github
4) At home, do a git clone to pull down the changes you pushed.
5) Now that the repository exists in both locations, you can simply do a git push before you leave work, and git pull when you get home, and vice-versa when going the other direction.
To answer the detail of your question: I'd go with Dropbox.
UbuntuOne is also good even for non Ubuntu users and of course Google drive is the (big) new player on the block.
They compare as follows:
Service Free*1 NextLevel*1 NextLevel($)*2 Features
Dropbox 2 50 $2.5O One Folder, best gui sync tools.
UbuntuOne 5 20 $4.00 Multiple directories anywhere
GDrive 5 25 $2.50 It's Google.
*1 GB
*2 Cost per month
To answer the title of your question:
If you wanted something that's more suited to programmers, I'd use git:
First, install gitx (linux readers, that's gitg) as that is by far the most popular gui for git:
For the "flow" I can also refer you to my write-up of various features at:
What are the core concepts of git, github, fork & branch. How does git compare to SVN?
Using gitx or gitg the specific flow is as follow:
1) Make some changes to files.
2) Use the tools "commit" tab to see what's changed ("unstaged"):
3) Add a file by dragging it from "unstaged" to "staged":
4) Give a commit message
5) Commit the file.
6) I then push it to the remote at the command line with $ git push remote or I use the gui by right clicking and select ing the 2nd master - see here:
.
If I'm sharing with others I'll often need to do git pull to get ands merge in others chnages) before being able to do a git push
The github part is doing init and push and clone but I'd say just read up on those tutorials more rather than an SO question. Basically though, I do:
Set up repository locally in git:
git init
git add .
git commit "Initial commit"
Set up github:
Create a github repository using github (https://help.github.com/articles/create-a-repo)and then push your local repository to it as in:
git push origin master.
If the repository already exists on github but not on your local pc, that's wheh you click the remote link and then in a terminal type git clone [paste here, e.g. ctrl-v]
If you're "starting" with github:
Make code changes
git pull - get latest version into your repository and merge in any changes
git add . Add all modified files
git commit -m "message"
git push # origin master is the default.
If, at the end of the day you decide to go with something simple like Dropbox you can use my referral link -http://db.tt/pZrz4t3k- to get a little more than the standard 2GB, Using this we both get an extra 0.5 GB, however which of all these routes to go is up to you and your needs. I use all these services (git, github, UbuntuOne, Dropbox and googleDrive, so I am not recommending one over the others -it depends on the needs).
I would recommend using DropBox or Google Drive. They will let you do EXACTLY what you are trying to achieve, they are very user friendly (and free [5 Gb I think]).
They automatically update (as long as you have an internet connection obviously)
Just make a folder, put some files in it, and you are away.
Since explaining how to use an entire VCS in one answer is an overwhelming task, I can instead point you in the direction of some very helpful resources to get you to understanding and using Git:
Pro Git - a free online book (written with Git!) with easy language on all things Git.
GitHub Help - GitHub's own help section walks you through setting up and using Git, and not just with their own apps. Very useful.
Get Started with Git - A good tutorial getting you up and running with Git.
Git For Ages 4 and Up - Fantastic video explaining the inner-workings of Git with Tinker Toys. Not best for an introduction into Git, but a great video to watch once you feel a bit more comfortable.
Git may feel complicated or strange at first, but if what you are looking for is a good version control system, it is excellent.
However, if all you're looking for is a cloud-like service to sync some files across multiple computers, like the others have mentioned, Dropbox would be the way to go.
I use Github as a "hub" of git, to share finished codes. (And Git for version control)
And Dropbox to sync files between different computers and mobile/tablet, to manage files.
http://db.tt/EuXOgGQ
They serve different purposes for me. Both are good!
Git is an advanced and rather difficult tool to use for version control. If you're feeling brave, you can try to install the command line tool, however I recommend using a graphical client, specifically SourceTree.
http://www.atlassian.com/software/sourcetree/overview
You'll need to clone your repository, or else initialize a new one. To connect to your repository, you'll need to know the URL, and possibly a username and password for your repository. You also need to provide a valid name for the repository.
To update files there are several steps: First, you need to add the changes to the directory. Source tree might do this automatically. Then you need to commit the changes. This is basically confirming changes and signing them with a comment. To upload them, you need to use push and select the correct remote repository. When you want to update your local repository, you'll need to use pull and again select the correct remote repository.
For your purposes, however, it seems like dropbox might be better, because it automatically updates and is very simple. If you don't need the advanced version control that git provides (e.g. branching, merging from many users), then it seems like it would be a better option for you.
https://www.dropbox.com/
I'm seriously about to stop coding and become a carpenter. This problem has had me stressed out for quite some time now and there doesn't seem to be any clear solution, other than forcing non-windows machines to use the file permissions windows seems to inflict.
Let's begin with the scenario. I have 2 development machines, one running Windows7, the other Mac OSX. They both are using Eclipse and EGit, and both have cloned the same project from a remote repo. That's where the similarities end, because my windows machine has a nasty habit of retaining a file mode of 644 (r-xr--r--) on its local repo, while the mode on the Mac defaults to a cool 775 (rwxrwxr--x).
So the problem's obviously the file permissions - GIT reports there are files that have changed due to differences in file modes and not actual content. The solution seemed obvious, run the following commands:
git config core.filemode false
git config --global core.filemode false
...which worked like a charm, except when committing and merging resolved conflicts.
For example, say files A, B and C exist on both the Windows and Mac repos. Next, let's change the file mode for these 3 files on the Mac machine so that the developer can edit them. Now change some of the contents in file A. Because we're ignoring the file modes (thanks to the commands above) only file A will be committed and pushed, ready for the Windows machine to fetch, merge and enjoy...
Now, let's edit file A again on the Mac and on the Windows machines, effectively causing a potential conflict, and let the Windows machine commit and push file A first. Then, when the Mac user commits their changes to file A and fetches the latest changes from the remote repo, a conflict is obviously created.
After resolving the conflict on the Mac machine and adding file A back to their local repo, committing that merge includes the previously ignored files B and C, and thus highlighting my problem! Why are the previously ignored files being included in this merge commit? This doesn't seem to be a Mac / Windows problem exclusively, as this problem can be recreated both ways...
This probably wouldn't matter if there were only 3 files, but this project I'm referring to includes thousands, and all these up and down push and pulls are insane. Am I missing something really obvious? Any help will be greatly appreciated!
So after a long and often frustrating run with trying to get Windows and Mac OS machines to like each other when comparing notes and changes over Git, it seems to just be the functionality of Git itself that's driven me mad, and a better understanding of how to better use Git seems to be the final answer.
Originally, I wanted to know how to continue ignoring file-mode changes (which Windows seemed to love updating with its own idea of what permissions and modes should be) while I was resolving conflicts created from updates to the files from someone else. Short answer: you can't. It's just the way Git works.
So how would you deal with this situation when it came up? Short answer again: use branching.
In my original way of using Git, I was continually working on my master branch on my local repo - bad idea already - so all my work would be committed there and all conflict resolution would need to be handled there too, forcing all files to be compared again and all permissions and file modes to come into question.
With branching, you work on another branch, commit to that branch, pull updates to your master branch, and merge you other branch with your master branch after that. Suddenly no more conflicts on the master from the remote repo, and you're winning!
Commands to do this (creating a branch from currently selected branch):
git branch newbranch
To checkout your new branch:
git checkout newbranch
To merge your new branch with your master branch (after you've committed to your newbranch, switch to the master first):
git checkout master
git merge newbranch
Hope this helps someone! -:)
well tbh, I'm not sure how you arrived at your conclusion since the obvious problem is git is not ignoring the file mode changes. This happens to us here too.
if you set that flag it seems to make no difference in some cases and still uses file modes to determine changed files.
that has to be a bug in git, what else could it be?
possibly your answer does not explain the rationale, therefore I dont think it's the correct answer, it's a workaround.
the correct answer is that git doesnt use filemode when it's told not to, it's obviously ignoring that and doing it anyway.
can you explain otherwise.
Here is my situation:
The project I'm working on right now
uses a version control system
(Microsoft Team Foundation) that's
hosted and managed remotely by the
customer. I am in charge of doing a
massive refactoring/bugfixing after
somebody who left a horrendous mess of
code behind. Due to several reasons
that I won't detail here* I cannot
commit to the version control my
incremental changes while I patch
things up; and there is no way I can
be given a separate branch there.
Here is my question:
I want a version control system that I can use locally. I can't just keep doing "zip source folder and backup it". I want a track of changes. I want commit messages. I want to see what I did and when and why in a couple of months. In a pinch, I'm tired to rely on VS 'undo' command and to leave comments myself tracking what I'm doing and how it was before.
Here is what I would do:
I'd install mercurial/git locally and start versioning my own directories.
Problem is, I am not sure this is the best way. Hints? Ideas? I am not familiar at all with either Visual Studio or Team Foundation and can't seem to find my way around with them (I don't know how things are 'named' so I don't know what I'm looking for). Is it possible, using such tools, to do what I have described?
*basically the customer doesn't necessarily have to know that our lead developer quit in anger and left the most horrendous code mess I've ever seen behind me; that at least 3 people 'tried to fix' his code in a rush to patch bugs; that this ended up in a single class with a 400+ long method including a single 'for' loop, at least 5 places where code is repeated-but-not-completely, unused logic, wrong comments, while(true) loops, and increasing the 'for' counter in the loop body to look-ahead into an array list. Basically, we hope the customer won't notice what's happening and if they do we can fix it when they whine.
The usual approach is to:
"git init" directly in the directory you want to manage locally
add a .gitignore in order to not add any VCS-specific data or directory
git add .gitignore and commit
git add .
commit
That way, you have a local repo you can then clone, make branches, patches, ...
(I do it for ClearCase views for instance)
A similar approach, with similar commands, is valid with Hg Mercurial of course.
I'm coming from a TortoiseSVN background and decided to give TortoiseHg a try. One thing I got really used to with TortoiseSVN was the SVN Repo-Explorer, which worked quite similarly to Windows Explorer. However, when I tried to use TortoiseHg's Repository Explorer, what I got was something else, it was more like TortoiseSVN's Show Log. It showed me what the recent commits were and what files were changed and even had nifty graphs. However, I'm still left wanting for TortoiseSVN's Repo-Explorer.
Does TortoiseHg have anything like this? How am I supposed to poke around the Repository if I can only view changed stuff?
I might be wrong as I have little experience with Hg myself, but I believe the reason TortoiseHg doesn't have a repository like its SVN counterpart is because Hg is a distributed VCS instead of a centralized VCS like SVN. So, the actual repository is your "checked out" copy. When you commit, you commit to your local repository, then you can push changes to other people or locations (such as google code, or your team mates). There are actually multiple different repositories for a project located in many places, instead of a single one, so there isn't really any meaning to "exploring the repository". The best you can do is check for incoming change-sets and view your local repository (using windows explorer).
This is mostly my reasoning based off a little experience with both. I might be wrong, but I hope this sounds reasonable.
This article might help clear it up: Distributed revision control. It took me some time to wrap my head around the idea of a distributed VCS too. In a nutshell, it's kinda like emailing your changes to your team mates. Everyone has their own individual repository, and each updates their own repository by getting change-sets from others.