Project

General

Profile

GettingPintosCode » History » Version 4

Borja Sotomayor, 12/09/2010 06:14 PM

1 1 Borja Sotomayor
h1. Getting the Pintos code into your PhoenixForge repository
2
3 2 Borja Sotomayor
Although you could just check out or export the Pintos code, and then commit it to your repository, we prefer that you use an intermediate _external branch_ in your repository. We don't expect that we'll have to make any changes to the provided Pintos code (since it has been pretty thoroughly tested in many other OS courses) but, if we do, using an external branch will make it easier for you to merge those changes into your code. The process for getting the code into your repository, by way of an external branch, is described here. These instructions are based on the "Vendor Branches" section of the SVN book. See http://svnbook.red-bean.com/en/1.5/svn.advanced.vendorbr.html for more details.
4
5
h2. Copying the code into your repository
6
7 1 Borja Sotomayor
To import the Pintos code into your repository, first do the following in a temporary directory:
8
9
<pre>
10 3 Borja Sotomayor
svn export https://phoenixforge.cs.uchicago.edu/svn/pintos/trunk pintos
11 1 Borja Sotomayor
</pre> 
12
13
14
This will create a directory called @pintos@, containing the Pintos code. Now, import it into your group's repository like this:
15
16
<pre>
17 4 Borja Sotomayor
svn import pintos https://phoenixforge.cs.uchicago.edu/svn/$CS230_GROUPNAME/external/pintos
18 1 Borja Sotomayor
</pre>
19
20
Notice how, we're not importing the Pintos code into the @trunk@ directory (which is typically used to contain the ``main branch'' of your code). To keep your code synchronized with the Pintos code, we are going to make use of SVN's merge functionality, which requires that we keep this @external@ code in a separate directory (the _external branch_). Of course, you still want to have your own copy where you will actually be writing your own code (the _main branch_). We make this copy like this:
21
22
<pre>
23 4 Borja Sotomayor
svn copy https://phoenixforge.cs.uchicago.edu/svn/$CS230_GROUPNAME/external/pintos \
24
         https://phoenixforge.cs.uchicago.edu/svn/$CS230_GROUPNAME/trunk/pintos \
25 1 Borja Sotomayor
         --parents
26
</pre>
27
28
29
Next, you need to create working copies for each of these two copies. _You need to keep these in separate directories_. So, in an empty directory (we will refer to it as @$BASE_DIR@) run the following to create a working copy of the Pintos code:
30
31
<pre>
32 4 Borja Sotomayor
svn checkout https://phoenixforge.cs.uchicago.edu/svn/$CS230_GROUPNAME/external/pintos
33 1 Borja Sotomayor
</pre>
34
35
And, _in a separate directory_ (we will refer to this one as @$MAIN_DIR@), run the following to create a working copy of your main branch:
36
37
<pre>
38 4 Borja Sotomayor
svn checkout https://phoenixforge.cs.uchicago.edu/svn/$CS230_GROUPNAME/trunk/pintos
39 1 Borja Sotomayor
</pre>
40
41 2 Borja Sotomayor
h2. Propagating changes into your repository
42 1 Borja Sotomayor
43 2 Borja Sotomayor
Now, let's say that there have been changes to the Pintos code that we provide. Merging them into your trunk is a two-step process:
44
45 1 Borja Sotomayor
# Update the external branch in your repository with the latest Pintos code.
46
# Merge the new Pintos code into your own, resolving any conflicts if necessary.
47
48
The first step is the kludgiest one, but also highly scriptable (SVN includes a script called @svn_load_dirs.pl@ that can help you automate this step. You essentially have to @svn import@ the Pintos code again, and overwrite the code in @$BASE_DIR@ with the newest version. If necessary, you may have to manually run @svn add@ to add new files and @svn delete@ to remove files that are no longer present in the latest version of the Pintos code. Once you have done this, just run @svn commit@ to commit the new version into your external branch.
49
50
The second step is handled by @svn merge@ which, in the best case, will automatically merge all the new code into your own but, in the worst case, will require you to resolve conflicts between your code and the latest version of the Pintos code. To merge the code, run the following
51
52
53
<pre>
54 4 Borja Sotomayor
svn merge https://phoenixforge.cs.uchicago.edu/svn/$CS230_GROUPNAME/external/pintos \
55 1 Borja Sotomayor
          $MAIN_DIR
56
</pre>
57
58
If you're lucky, and there are no conflicts, you will see something like this:
59
60
<pre>
61
--- Merging r3 through r5 into 'pintos':
62
U    pintos/tests/main.h
63
U    pintos/Makefile.kernel
64
</pre>
65
66
If a conflict happens, then you will be given the option to resolve it manually:
67
68 2 Borja Sotomayor
<pre>
69 1 Borja Sotomayor
Conflict discovered in 'pintos/tests/main.h'.
70
Select: (p) postpone, (df) diff-full, (e) edit,
71 2 Borja Sotomayor
        (h) help for more options:
72
</pre> 
73 1 Borja Sotomayor
74
@df@ will show a diff between your code and the code you are merging in, and @e@ will allow you to edit your code to resolve the conflicts manually. Once you've edited the file, you will be allowed to select the option @(r) resolve@.
75
76
Once the merge is complete, you have to run @svn commit@ to actually commit the merged version into your main branch.