The instructions for the 'advance testing setup' at the end of chapter 3 (3.7) of the book online suggest to checkout to the master branch before making changes.
Would not be convenient to add and commit these changes with git add -A and git commit -m? I am wondering whether there is some reason for these commands to be omitted at this stage, or they are supposed to be implicit.
No there where no good reasons for omitting them and either he forget about them or implies them, so use them as long as you can;)
I think Hartl states somewhere near the beginning of Chapter 3 that from then on, he will omit the git commit/git add steps from the text for simplicity, but that using them as he directed in the previous chapters is his recommended method for working.
Related
I have never used a version control system before, and am rather confused about the very first steps. In a personal PIC/MPLAB programming project, under Linux, (no one else involved), with a single source code file that will go through several development stages as I add and verify features, I want to keep the set of "working so far" source code files, and Mercurial looks like a very good way to do it, preferable to my usual, and error prone, ad hoc approach.
So I have a very elementary question: I have installed Mercurial and accessed it from within MPLAB, and I have created a file
"/home/Harry/MPLABXProjects/flash675.X/.hg"
Please, I want to know 1) what to do next to start it off and 2) is it going to be obvious how I go about using the Mercurial system from then on? I find the documentation confusing on this very basic point.
(Yes, the first stage is just flash an LED, using a TMR0 interrupt, and that is working ok; I will then use that as a "prover" that the hardware is still working when I get to the inevitable "nothing happening" situations. I am building an ammeter for a p.s.u. with a Hall effect transducer, so I later will be adding an 8-LED serial display for debugging, a 12-bit A/D converter and a 4-digit 7-segment display, all using I2C serial control)
Good answer to this question will have the size of a full tutorial. There are many existing tutorials in the Internet, http://hginit.com/ for example. You can walk through it but I suggest to look at Mercurial: The Definitive Guide (link). The beginning of the book has a form of tutorial so it won't take a lot of time too.
The best helpers in learning is practice and experiments. Just don't forget to keep clean copy of your repository. It will save you when you break one of repository's clones. Here is a quick instruction so my answer won't be too philosophical.
Create your "prover". For example, it is a file called prover.c.
Look what you have: hg status. You will see your file with question mark. It means this file isn't under version control.
Add it to repository: hg add prover.c. Doing this you register your file in repository. After you commit Mercurial will start tracking changes in this file.
Commit: hd commit. You will be asked to enter a commit message. Good comments will help to discover a history in future.
That's it. If you change prover.c now and run hg status you will see that Mercurial knows about all changes. You can ask Mercurial to show changes by run hg diff.
We are working on a single project, and also committing code at the end of day on SVN so that can get all update project. But issues is very often our code getting errors while committing code and projects get empty if someone get update at that time. So my question is are there any set of rules which we've to follow on committing so that every one go on straight path and no one get in trouble and save a lot time from these errors.
Thanks in advance. Cheers
Search Google, something similar to "source control best practices".
Top result has several tips. Sounds like the biggest problem you're facing is integrating with others' changes. Perhaps look into the following sections:
Incorporate others' changes frequently
Share your changes frequently
Coordinate with your co-workers
Investigate why you get errors. Blind application of rules is not good.
For example:
person A committed a code producing compilation error
why?
he finished his task, but hasn't checked build before committing to the trunk
why?
the entire build it too slow
solution: speed-up build, set up continuous build system which will check every commit and notify developers about problems as soon as possible
Another example:
person B committed a code which breaks the build
why?
he wanted to store his changes, but the task is not finished
solution: advice him to create a branch, when the task is finished it can be merged to the trunk (if branch lives for long time, merge changes from trunk to it periodically, then the merge will not be a problem)
There possible other scenarios. With more details you will be able to ask more precise question on StackOverflow and get better answers.
In case of use of SVN co-ordination is must between the team.
Make sure whenever you commit the code you have a idea about what are you committing.
The golden rule is "One developer One class".
If at all two different developers are working on same class. Ask them to maintain a document on what changes they have made. And, most important to mark a comments in a class it self.
There are some important things which need to be followed while committing the code. Whenever you see a conflict in your local files and server files. Make sure you go through every conflict and select the appropriate action.
Understand one important thing, whenever SVN is used one persons mistake can affect everyone.
Whenever possible, don't edit the same line of code as someone else
Leave meaningful comments on your commit messages
Comment your code
Make sure that all the code you commit compiles and runs as it should
Commit when appropriate ie: are passing off part of your code to be used by others or are done working on a feature
Make sure to communicate with other team members
If you find code that you don't know what it does, ask the author
If you're making major changes that will take a while to implement, use a branch and then merge it back in
I'm trying to set up version control for a programming-related tutorial. It's proving problematic because there are two different kinds of history:
There's the history of the project being built by the tutorial, which is available for each chapter and is what the reader will see. If I never planned to change already-written chapters of the tutorial again, I could just store each chapter as a tag in the history of the project.
Then there's also the history of the tutorial itself (not only the text, but my working on the pretend history of the project). If I find a bug I need to go back and fix in chapter 1, adding a new commit to the end doesn't work because I want to change how the project "appeared" at that stage, i.e. insert a commit in the project history and move the chapter's tag forward.
So far I've thought about a few possibilities- using git branches where each chapter is a branch that gets rebased to the front of the previous chapter whenever I make a change, a mercurial patch queue that I insert patches into, or structuring the tutorial around a set of modules that I could put in subrepositories.
I thought I'd ask if anyone has experience with this kind of thing and what solutions worked and didn't.
Rather than rewriting the history of the all project because of a late fix to an early chapter, I would rather isolate each chapter in its own branch, have each HEAD representing the current state for each chapter.
Assembling the all tutorial is then more a release management issue (deploying your tutorial by extracting the relevant informations from the Git Repo).
You can then develop your tutorial to achieve something similar to git immersion.
(Note: If this was more an ebook you were after, then git-scribe would have been a more interesting way to version it.)
The OP rusky adds in the comments:
I'm trying to version the sample code for the chapters, where each chapter's code is based on the previous chapter's code
That means any bugfix you add needs to be reported to the other branches representing the other chapters, in which case see:
In Git, how do you apply a commit of bug fix to the other newer branches? (avoiding cherry-picking, which is generally a bad idea)
using a topic branch
rebase --onto solution
git rebase --interactive is probably the most straightforward solution here. That will let you choose a specific commit to edit, then reapply all the subsequent commits on top of it. Shouldn't be much more difficult than a regular merge, depending on how extensive your change is, of course. Check out the part of the git rebase man page on splitting commits. That will let you keep your original version for historical reasons, then add a new commit just after it in the history where you can move your tag.
The great thing about CLI-based version control is you can use shell scripts to build up tutorial examples, something like:
#!/bin/bash
mkdir example_repo
cd example_repo
git init .
touch file1
git add file1
git commit -m "Added file 1"
git checkout -b branch2
echo "New line" > file1
git commit -am "Added new line to file 1"
You get the idea. It lets you build up a new repo from scratch to whatever point you like, and mistakes in the middle are easy to fix because you start from a blank slate every time. You can put the shell script itself under version control, or just comment out parts you don't need for different examples.
This is what tags are for. Tag your "snapshot" points, and go from there. If you need to go back and change something, do so and update the tag. And if you don't want people to see the in-between stages, simply create a second repository and incrementally check in your commits one tag at a time.
I organized code incorrectly in a game I'm developing, and intend to move the state update code from GameView class into the Level class. I would like to record this cut-and-paste in some way. I use Mercurial for versioning. Is this possible with Mercurial? Does any other VCS provide this feature?
Reading a bit more and watching Linus' talk about git at Google, as well as reviewing answers and comments, I understand that this is a feature of git's blame command and works by doing heuristics.
I could get this functionality by using hg-git, exporting the Mercurial changesets, and then just using the git blame -M -C command. Is there an easier way that does not involve git?
If it is not, I'll accept an existing answer that mentions git and describes using its functionality best.
git does this automatically. See How does Git track history during a refactoring?
If the level class doesn't already exist you can do it with:
hg copy GameView.ext Level.ext
and then delete from GameView whatever you've moving to Level, and modify Level to reflect the correct name and exclude everything that's staying in GameView.
If Level already existed I don't think there's any good way to do it unless you're willing to extract that code out into its own class that could start out as a copy of GameView and be included (via #include, or composition, or extension) in Level.
I don't think that Mercurial tracks file renames/moves explicitly, at least it's not a part of a changeset (although it can guess where a particular file came from based on it's content).
That being said, I'm afraid that I'm not aware of any VCS that tracks movement of code between files, just addition to the target and subtraction from the source.
Mercurial supports file rename detection as follows:
hg addremove -s 100
The -s means "similarity" and the 100 means 100%. It will look for files whose name has changed but their content remains identical.
I quite often use this command with a 85 or 90% similarity figure. And in combination with the -n switch which allows a dry run (i.e. do nothing but report), it can be very powerful.
Detection of actual moved code is not really possible I don't think.
What I do for this sort of situation is isolate the changes from my other development, then commit the movement in a single commit with a note, "moved function munge() between files.
To my knowledge, no VCS tracks the movement of data. Renames are trackable with git and Clearcase.
Is it possible to have different development "paths" from a given point in Mercurial, without having to clone my project? I currently have 2-3 different implementations options for a project and I'd like to try them out. If I could just use one and at any point come back and start in another "path" without losing data from the older one that would be nice, but I am not even sure it is possible.
Thanks
This is exactly what branching is designed for:
https://www.mercurial-scm.org/wiki/Branch
The easiest way to create a branch in Mercurial is to simply checkout an older version, and then commit again with something different from what you committed after it the first time. You won't lose the old following commit, the new commit will simply branch out into a new line of development and the original commit(s) will remain on the previous line of development.
Yes, you probably want bookmarks for this - they're a lightweight way of marking various heads without recording the names forever in the revision (which branches do.) See BookmarksExtension for more details.
http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ may also be helpful - it's essentially the canonical document on branch management strategies in Mercurial.