Recent Changes - Search:


Reference:

C

edit SideBar

Versioncontrol

git

Branching with git

  • A nice explanation about branching can be found here.

Briefly:

 git branch experimental
adds branch experimental
 git branch
shows you all branches and marks the current with a asterisk
 git checkout experimental
 (edit file)
 git commit -a
 git checkout master
makes a change to a file but you do not see it in master branch

Then edit same file in master branch and your branches have diverged. To merge the changes:

 git merge experimental
 git diff
if nothing comes up, you can be happy otherwise you have to merge by hand the shown positions.

Deletion of branches:

 git branch -d experimental
ensures local changes are already in the current branch
 git branch -D experimental
throw away despite any local changes

If you want to share your tags with other, push it to the remote repository:

 git push --tags
the option --tags is necessary, by default only changes to master branch are being pushed.

Tagging w/t git

Create a tag by:

 git tag -a tagname

List all tags:

 git tag -l

or

 git show tagname

Basics

After recognizing that subversion do not want to checkout my old repository after upgrade from etch to lenny because of the update of the DB file system Berkeley 4.4 to 4.6 I decided to change to git.

Getting message during pull operation

 If you often merge with the same branch, you may want to
 configure the following variables in your configuration file:

    branch.master.remote = <nickname>
    branch.master.merge = <remote-ref>
    remote.<nickname>.url = <url>
    remote.<nickname>.fetch = <refspec>

You can do this:

 git config branch.master.remote origin
 git config branch.master.merge refs/heads/master

git version differences

 git show c2d8ea11b4e6aeb605aeef35fad261846d142ff6 file.txt

Shows the differences between this commit and the one before.

init new repository

 git init
creates .git directory in the current folder which stores the complete information
 git add filename
 git commit -m 'comment'
 gitk

To recover accidentally deleted files:

 git ls-files -d
shows files that were deleted
 git ls-files -d | xargs git checkout --
recover these files

The following creates a remote repository:

 ssh remoteserver.com
 mkdir /var/git/myapp && cd /var/git/myapp
 git --bare init
 Initialized empty Git repository
 exit

on local site:

 cd ~/workspace/git/myapp
 git remote add origin ssh://remoteserver.com/var/git/myapp
 git push origin master

This was found here.

Create an authoritive repository from an existing one

Assume ~/existing-git-rep is already a Git repository.

 $git clone --bare ~/existing-git-rep ssh://user@remotehost.net/home/user/repsoitory.git
 $cd ~/existing-git-rep 
 $git remote add origin ssh://user@remotehost.net/home/user/repsoitory.git
 $git remote update
 ... do some changes to local repository
 $git push origin
 ... someone else do some work on his repsository and pushes it to the authoritive rep.
 $git pull

subversion

gives each line of source with information about author and revision

  svn blame source.c
  svn ann   source.c

change attributes from files that are contained in repository

  $svn propdel svn:executable source.hpp
  property 'svn:executable' deleted from 'source.hpp'.
Deletes the executable bit from source.hpp which was set because it was copied from a windows system.

Advanced svn techniques

Using external editor for commits
  • in directory /home/$USER/.subversion
  • Open the file config and add the following line to the file
 editor-cmd = "editor"
replace "editor" with your prefered editor
Using your prefered diff tool
 diff-tool-cmd = "svn_diff"
svn_diff is a script that diverts the 6th and 7th parameter further to gvimdiff or whatever editor else.

Or you can use

 svn diff -r 123:132 asdf.txt --diff-cmd=echo

to see what the wrapper needs to do with the stream from svn.

 svn diff -r 123:132 asdf.txt --diff-cmd=gvimdiff
svn export

to export an arbitrary version of some project without subversion information (.svn folders)

svn basics

 svnadmin create /repository

 svn import path2project/file file://path2repository -m 'comment'
 svn checkout file://path2repository where2place
 svn co svn+ssh://servername/repository where2place
 svn add filename
 svn commit -m ''
 svn delete filename
 svn move oldname newname
 svn update # gets changes from repository

 # examine your changes
 svn status
 svn diff
 svn revert

 # examine local changes
 svn diff

 # comparing working copy to repository
 svn diff --revision 3 foo.c

 # comparing repository to repository 
 svn diff --revision 2:3 foo.c

If you want to examine an earlier version of a file and not cecessarily the differences between two files, you can use svn cat:

 svn cat --revision 2 foo.c

 # logs
 svn log --revision 5:19 
shows logs 5 through 19 in chronological order
 svn log -r 19:5
shows logs 5 through 19 in reverse order
 svn log -r 8
shows log for revision 8
  1. merge others' changes
 svn merge
 svn resolved

 svn status --verbose
 svn status --show-updates --verbose

 svn diff > patchfile
  1. make the changes which you have made accidentally
 svn revert foo.c
  1. resolving conflicts
 svn commit -m ''
 svn: commit failed ... foo.c remains in conflict
  • merge the conflicted text by hand foo.mine foo.r23 foo.24
  • or copy foo.r24 to foo.c
  • or run svn revert foo.c to throw away all you local changes

Then you can run

 svn resolved foo.c

to inform svn that you have resolved the conflict with this file.

Merging

you made the changes

 <<<< .mine
 blabla
 ====

Someone's changes are here

 ====
 blub
 >>>>>> .r23

If you want to change the server where the repository lies you only have to copy (secure with scp over openssh) the whole repository folder to the new server and there you start the svn daemon with:

 svnserve -d
this opens a port on 3690

If you want only secure connections to the server you can write a rule with iptables:

 $IPTABLES -A INPUT -p tcp --destination-port 22 -j ACCEPT
 $IPTABLES -A INPUT -p tcp --destination-port 3690 -s 127.0.0.1 -d 127.0.0.1 -j ACCEPT
 $IPTABLES -A INPUT -p tcp --destination-port 3690 -j DROP

then the local connections to 3690 will be permitted the rest not. From outside only tcp on port 22 (ssh) is allowed.

Examining History

There are several commands that can provide you with historical data from the repository:

 svn log

    Shows you broad information: log messages attached to revisions, and which paths changed in each revision.
 svn diff

    Shows you the specific details of how a file changed over time.
 svn cat

    This is used to retrieve any file as it existed in a particular revision number and display it on your screen.
 svn list

    Displays the files in a directory for any given revision.

 svn log

 svn log --revision 5:19    # shows logs 5 through 19 in chronological order
 svn log -r 19:5            # shows logs 5 through 19 in reverse order
 svn log foo.c
 svn log -r 8 -v
 svn diff --revision 3 rules.txt 

If you want to examine an earlier version of a file and not necessarily the differences between two files, you can use svn cat:

 svn cat --revision 2 rules.txt 
 svn cat --revision 2 rules.txt > rules.txt.v2

In addition to all of the above commands, you can use svn update and svn checkout with the --revision switch to take an entire working copy “back in time”

 svn checkout --revision 1729 # Checks out a new working copy at r1729
 svn update --revision 1729 # Updates an existing working copy to r1729

Sometimes an administrator might change the “base location” of your repository—in other words, the contents of the repository doesn't change, but the main URL used to reach the root of the repository does. For example, the hostname may change, the URL scheme may change, or any part of the URL which leads to the repository itself may change. Rather than check out a new working copy, you can have the svn switch command “rewrite” the beginnings of all the URLs in your working copy. Use the --relocate option to do the substitution. No file contents are changed, nor is the repository contacted. It's similar to running a Perl script over your working copy .svn/ directories which runs s/OldRoot/NewRoot/.

 cd /repository-path
 svn switch --relocate  file:///tmp/repos file:///tmp/newlocation .
  • HEAD: The latest revision in the repository
  • BASE: The pristine revision of an item in a working copy.
  • COMMITTED: The last revision in which an item changed before BASE
  • PREV: The revision just before the last revision in which an item changed.
 svn diff --revision PREV:COMMITTED foo.c
shows the last change committed to foo.c
 svn log --revision HEAD
shows log message for the latest repository commit
 svn diff --revision HEAD
compares your working file with local mods to the latest version in the repository.
 svn diff --revision BASE:HEAD foo.c
compares your pristine foo.c (no local mods) with the latest version in the repository
 svn log --revision BASE:HEAD
shows all commit logs since you last updated
 svn update --revision PREV foo.c
rewinds the last change on foo.c which leads to decreasing the foo.c's working revision

Revision Dates

 svn checkout --revision {2008-08-01}
 svn checkout --revision {15:30}
 svn checkout --revision {15:30:23.2000000}
 svn checkout --revision {"2008-08-01 15:30"}
 svn checkout --revision {"2008-01-01 15:30 +0230}
 svn checkout --revision {2008-01-01T15:30Z}
 svn checkout --revision {20080202T1530-0500}

 svn log --revision {2002-11-11}:{2002-12-01}
finds all revisions between both dates
 svn log --revision {2002-01-01}:4711
finds all revisions between date and revision number.

Branches with svn

Assume that you have prj23 as project folder and you have some big steps to do with your project. Until you finish the changes you want that the other guys who are working with the same project do not note something of the changes. For that reason you can establish a new branch. This new branch should be created in the folder ./mybranch:

 svn copy prj23 mybranch
 svn status
 A + mybranch
 svn commit -m ""

The character '+' shows that this folder is only a copy and not a complete new folder.

Merging branches again to one branch

Assume you have a original version and two branches of project prj23. Lets name these branch1 and branch2. Then some guys will edit many changes. Then you want the changes from branch1 merge into the branch2. Just go to the folder where the two branches folder lie and type:

 svn log -v 
to get the oldest revision where branch1 was created. Lets call it 303.
 svn merge --revision 303:342 branch1 branch2
342 is the newest revision of branch1.

Afterwards you have the changes which were made to branch1 also in branch2.

undoing changes

If you commit something to revision 303 and later you recognize that the changes were totally wrong. They have never been committed. So you can make a merge back:

 svn merge -r 303:302 prj23

creating releases

You have reached a specific development status and want to hold this status as release 1.0:

 svn copy prj23 releases/prj23-1.0 -m "release 1.0"

Afterwards be sure not to commiting to these folders because it is the same as a branch and the commits will change the release to a newer state. But this is usally not what you want.

cvs

 CVSROOT=/path2archive
 cd $CVSROOT; cvs init
 cd source
 cvs import -m 'bla' projectname user alpha vendor release
 cd workingfolder
 cvs checkout projectname
 cd workingfolder/projectname
 # make some changes
 cvs update
 cvs -Q diff -c
 cvs commit -m 'asdf'
 cvs status main.c
 cvs edit main.c
 cvs watch main.c
 mkdir test 
 cvs add test
 touch test/a.c
 cvs add test/a.c
 cvs commit -m ''
Edit - History - Print - Recent Changes - Search
Page last modified on June 10, 2010, at 10:17 AM