Pull. Video. Powerpoint. TracStandalone. Note: this page documents the version 1.0 of Trac, see 0.12/TracStandalone if you need the previous version Tracd is a lightweight standalone Trac web server. It can be used in a variety of situations, from a test or development server to a multiprocess setup behind another web server used as a load balancer. Pros ¶ Fewer dependencies: You don't need to install apache or any other web-server.
Cons ¶ Fewer features: Tracd implements a very simple web-server and is not as configurable or as scalable as Apache httpd. Usage examples ¶ A single project on port 8080. . $ tracd -p 8080 /path/to/project Strictly speaking this will make your Trac accessible to everybody from your network rather than localhost only. . $ tracd --hostname=localhost -p 8080 /path/to/project With more than one project. . $ tracd -p 8080 /path/to/project1 /path/to/project2 You can't have the last portion of the path identical between the projects since Trac uses that name to keep the URLs of the different projects unique. Where: How to create patch file using patch and diff. November 23rd, 2006 mysurface Posted in Developer, diff, Misc, patch | Hits: 323569 | 14 Comments » Okay, this is what I do.
I only know the basic. But before doing this, please backup your source code, patch wrongly will screwup your source code. First, how to create patch file? Patch file is a readable file that created by diff with -c (context output format). Assume Original source code at folder Tb01, and latest source code at folder Tb02. Diff -crB Tb01 Tb02 > Tb02.patch -c context, -r recursive (multiple levels dir), -B is to ignore Blank Lines. How to patch? Doing dry-run like this: patch --dry-run -p1 -i Tb02.patch The success output looks like this: patching file TbApi.cpp patching file TbApi.h patching file TbCard.cpp ... The failure ouptut looks like this: patching file TbCard.cpp Hunk #2 FAILED at 585. 1 out of 2 hunks FAILED -- saving rejects to file TbCard.cpp.rej patching file TbCard.h Hunk #1 FAILED at 57. Patch -p1 -i Tb02.patch References: 1.
Git for Computer Scientists. Abstract Quick introduction to git internals for people who are not scared by words like Directed Acyclic Graph. Storage In simplified form, git object storage is "just" a DAG of objects, with a handful of different types of objects. They are all stored compressed and identified by an SHA-1 hash (that, incidentally, isn't the SHA-1 of the contents of the file they represent, but of their representation in git). blob: The simplest object, just a bunch of bytes. This is often a file, but can be a symlink or pretty much anything else. Tree: Directories are represented by tree object.
When a node points to another node in the DAG, it depends on the other node: it cannot exist without it. Commit: A commit refers to a tree that represents the state of the files at the time of the commit. Refs: References, or heads or branches, are like post-it notes slapped on a node in the DAG. Git commit adds a node to the DAG and moves the post-it note for current branch to this new node. History. Git from the bottom up. In my pursuit to understand Git, it’s been helpful for me to understand it from the bottom up — rather than look at it only in terms of its high-level commands. And since Git is so beautifully simple when viewed this way, I thought others might be interested to read what I’ve found, and perhaps avoid the pain I went through finding it. The following article offers what I’ve learned on this journey so far. I hope it can help others to comprehend this wonderful system, and discover some of the joy I’ve experienced in the past few weeks.
NOTE: After receiving more than fifty corrections by e-mail from very helpful readers, I’ve updated the PDF to reflect their input. The date at the front should read “December 2009″ if you have the latest version. Here is a summary from the table of contents: