Little hg Help..
Monkey Archive Forums/Digital Discussion/Little hg Help..
| ||
| ok.. I have a project called T, which I am controlling via hg, but in all honesty I am a total source control noob, and would love some tips advice on the following thing. At the moment I am simply committing my changes over time, commit often I think was the tip I read, so that's what I do, what I would like to try now however is a Branch. I have some new code, those lines in my apps gallery, I want to implement those as bullet and ship trails but there is a risk that it might drop my frame rates bellow my target, so what I would love to try is create a branch, add this code to the branch and then only if it works, add it back to the main master. Now saying all that makes me sound like I might actually know what the hell I was just talking about, but I really don't , have no clue what my next step should be or how to go about any of it. I could go look this up in google, but I am dyslexic, and I have found that most things source control come with massive walls of text which just make my brain hurt in a way you probably cant understand. so what I would really love is a few simple steps that I should follow to try this. well hope some one has the time and skills to throw up a reply. and thanks in advance. |
| ||
| When you commit, give it a branch name other than default. From then on, any commits will be based on that. When you're ready to merge, update back to the default branch and (if you're using tortoise) right click the latest changeset in the workbench and choose "merge with local". Resolve any conflicts and commit it. I'd give you screenshots, but I'm on the bus. |
| ||
| The step-by-step for that (for Tortoise) is: [Skip step 1 and 3 if you're not pushing to a remote repository] 1. Set your synchronise settings to allow pushing of named branches: 1.1 Choose TortoiseHg -> Synchronise from the context menu (right click on repos in explorer) 1.2 Click options 1.3 Select "Allow push of new branch", OK, and close sync window 2. Commit to new branch 2.1 Go to commit as usual 2.2 Click "Branch: default" at top of commit window 2.3 Select "open a new branch named whatever" 2.4 Commit as usual 3. Push your changes to remote repository 4. When you want to switch between branches (without merging): 4.1 Make sure all your changes to current branch have been committed 4.2 Open workbench for your repos 4.3 Right-click latest changeset for the branch you want to switch to, and choose update 5. When you want to merge your changes into another branch, it's the same as 4, but choose "merge with local" at step 4.3, then resolve, commit, and push as necessary |
| ||
Click the button labelled "Branch: default" just above your commit message. Select "Open a new named branch" and give it a name. Click OK.  Click Commit, then "Create Branch".  When you've made some changes and you're ready to merge, update to the default tip.  Right click the latest commit on the test branch, and choose "Merge with local".  Go through the merge process (mostly clicking Next), and choose "Commit Now" if you're ready. Otherwise click "Commit Later", and you can make some final changes before committing. Merging is another topic, however. :) Edit: I see Kalakian beat me to it, however I find pictures helpful. |
| ||
| will have questions, will post em tomorrow when I get a chance to read this, posting from my phone.. thanks guys.. |
| ||
| OK.. I'm awake now and had a chance to read that, thanks for posting guys just a few things I wana try and wrap my brain around with your help.. So when I make a branch, I do NOT! need to create another local copy of the source, the control system handles all that, when I work on the branch if I say add new sounds, sprites, lots of new code, and then jump back to the main branch the source control system will move/hide/magic ? those branched files out the way leaving me with the main branch source and files again and vice versa, would that be correct ? |
| ||
| That's correct, it all works by magic :) If everything is committed, you're fine. Your actual repository (all branches and history) is stored inside the .hg folder, so just don't delete that! I always push to a remote repository so I have a backup in case something goes wrong (handy if I move computers too). |
| ||
| yeah I'v been keeping my backups on thre clouds, Dropbox, GDrive and SugerSync thanks for the info, feel confident enough to actually try this for the first time, plan to make a full backup before I do tho just in case it all goes tits up. |
| ||
| How is this any better than me rarring up my project folder when I complete certain features, leaving me with incremental backups of my project. I code alone, don't share code and only use a single machine. I'm interested, but not sure if the extra hassle and effort is worth any advantages it may bring over "right-click->Add to .rar archive". |
| ||
| I will leave that upto one of the others to answer im still new as is evident from this thread, but I will say that when I was finally talked into it, after a very short period of time I was increadibly happy and thankful, I could tell early on that it was a good thing, you should give it a bash. |
| ||
| I've got them installed to grab Diddy, SpriterImporter etc, but it just seems like overkill for me atm, although I am looking at them as my project will be growing quite big soon so am considering my options. Why were you happy and thankful? |
| ||
| Creating archives of code is quite limited, but can sometimes be enough for solo or small projects (as you obviously know). Using source control, you have way more options available to you. Each time you commit, you add a comment, and the files are recorded at that specific version. This can allow you to go back and see how things have developed at a file level, not just at an archive level. It's also a lot more convenient than having to un-rar old snapshots if you're trying to track down which code change has introduced a bug. As for branches, you can work on multiple of them at the same time. Say you have a couple of different features you want to test out, but they make take a while to implement, and you need to continue development of the main features in the meantime. Sure, you could just use separate folders and work on different copies, but what if you need to port changes from one to the other ... there's a lot more work involved if you are manually tracking which files have changed in each copy, while source control can do this for you. There are lots of other benefits to using source control, but the best way to find out is to start using it. Everybody has their own style of workflow, so it's hard to pinpoint exactly how this would benefit YOU, so the benefits I mentioned are very general. |
| ||
| Thanks for that Kalakian, it makes sense. Which should I use as a beginner? I have TortoiseHG and TortoiseSVN installled already so I may as well give one of those a go, although all this branch/fork/commit/merge confuses me at the moment so I will play with some small demo files to get my head around it. taiphoz: Sorry for the thread hijack. |
| ||
| I'd recommend Mercurial (Hg), though Git is quite good as well. SVN is fine at the start, but when you get onto the more complex features, you'll want to move away from it anyway (branching sucks), so may as well go for Hg right away. Don't worry about branches, forks, or merging until you get used to the committing side of things. If working on your own, you probably won't need update so much (since you have the most up-to-date code), but it's a good idea to get used to push and pull early on. You can create a local repository just by right-clicking on an empty folder and choosing TortoiseHg->Create repository here. You should then get used to adding and ignoring files, and committing. Moving on from there, create a free account at bitbucket.org, add a new Mercurial repository, and you can push from your local repository to it. http://hginit.com/00.html is a great tutorial for Mercurial. If you've never used subversion, just skip to the second page and never look back :) |
| ||
| That tutorial is for the command line, but the commands map quite well to TortoiseHg menu options. If you do get stuck though, just ask away and I'll see if I can help out (I'm no expert though). |
| ||
| @Kalakian: If you've never used subversion, just skip to the second page and never look back :) Agreed. Subversion breeds bad habits. I'd hazard that it's easier for someone who's never used source control to pick up Hg/Git than it is for someone who started with SVN. |
| ||
| If you want to go with git, this is a nice introduction: http://rogerdudler.github.com/git-guide/ Also, if you are somewhat confident with the shell I would definetely recommend using that. Before I was at the Uni I used a gui tool but have found that except for viewing a big project a gui just gets in the way. More importantly, using the command line I better understood how git works and it also feels faster too me(subjective). |
   |