Permalink
Browse files

Merge remote branch 'origin/leto/git_docs'

  • Loading branch information...
2 parents 3fd70ea + 15398a7 commit 8beef6b0634bdf4f34a4e5f74ecd062bcd94a869 @leto leto committed Nov 8, 2010
View
1 MANIFEST
@@ -506,7 +506,6 @@ editor/pasm.vim []
editor/pir-mode.el []
editor/pir_vim.in []
editor/pmc.vim []
-editor/subversion_config []
examples/README [examples]
examples/benchmarks/addit.pasm [examples]
examples/benchmarks/addit.pir [examples]
View
2 RESPONSIBLE_PARTIES
@@ -3,7 +3,7 @@
This is a list of project roles, with a partial list of the folks who have
taken responsibility for them. This does not list all the people with
-SVN commit access, just those who have a role they've taken responsibility
+commit access, just those who have a role they've taken responsibility
for.
See docs/project/roles_responsibilities.pod for role definitions, and
View
8 docs/book/draft/appb_patch_submission.pod
@@ -33,14 +33,14 @@ committers and testers have a better idea about what it does. The body of
your email should also include a good description about what you changed
and why.
-It's important that you create your patches from a checked-out subversion
+It's important that you create your patches from the Parrot git
repository, not from a tarball or a snapshot. This way, you can ensure
that your diff is made against the latest version of the files. If you patch
an old version, the problem may have already been resolved! Make sure
the paths listed in the patch match those in the repository. There are two
methods of creating patches that will do this for you. You can make changes
-directly in your checked-out copy of the subversion repository and
-then create diffs using the command C<svn diff>. Alternatively, you can
+directly in your clone of the git repository and
+then create diffs using the command C<git diff>. Alternatively, you can
make a copy of the repository and then create diffs between the two
copies with the C<diff -u> command:
@@ -81,7 +81,7 @@ message should clearly explain what the patch is supposed to do and
why you're submitting it. Make a note if you're adding or deleting
files so they won't be missed.
-Here is a good example of a patch submission using the subversion diff
+Here is a good example of a patch submission using the git diff
method (an actual patch from p2). It's short, sticks to the point, and
clearly expresses the problem and the solution. The patch filename and
the subject of the message are both descriptive:
View
8 docs/book/draft/appd_build_options.pod
@@ -23,11 +23,11 @@ will typically have access to the C<make> command as part of the normal
development tools. Windows systems can get the C<nmake> utility to perform the
same task.
-=item * Subversion
+=item * Git
-Subversion is the source control system that is used by the Parrot project.
-You need subversion to checkout the latest version of the source code. You can
-get subversion at L<http://subversion.tigris.org>, or through one of the
+Git is the source control system that is used by the Parrot project.
+You need git to clone the latest version of the source code. You can
+get git at L<http://git-scm.com>, or through one of the
common packaging systems.
=item * bison and flex
View
10 docs/book/draft/appe_source_code.pod
@@ -12,18 +12,18 @@ platforms, including Windows, Debian, and Redhat. Point releases are
available from U<http://www.parrot.org/download>.
If you plan to get involved in development, you'll want to check out
-the source from the subversion repository directly. Anyone can get
+the source from the git repository directly. Anyone can get
anonymous access to read the files and download a working copy to
explore and test. For commit access, volunteers need a
U<https://trac.parrot.org> username, and need to be approved by a
-Metacommitter. To download the most recent version from SVN, type this
+Metacommitter. To download the most recent version from git, type this
command into your terminal N<This is for Linux users, on Mac or
-Windows systems, follow the instructions from your SVN client>:
+Windows systems, follow the instructions from your git client>:
- svn co https://svn.parrot.org/parrot/trunk parrot
+ git clone http://github.com/parrot/parrot
There's also a web interface for viewing files in the repository at
-U<http://svn.parrot.org/parrot/>.
+the same link.
The repository is large and complex, so it's worth taking a little bit
of time to explore. The code changes constantly, but most files and
View
2 docs/book/draft/ch01_introduction.pod
@@ -115,7 +115,7 @@ X<metacommitter role>
Metacommitters manage commit access to the Parrot repository. Once a
contributor is selected for commit access, a metacommitter gives the new
-committer access to the SVN repository and the bugtracker. The architect is a
+committer access to the repository and the bugtracker. The architect is a
metacommitter, but other team members also hold this role.
=item Committer
View
2 docs/book/pct/ch01_introduction.pod
@@ -115,7 +115,7 @@ X<metacommitter role>
Metacommitters manage commit access to the Parrot repository. Once a
contributor is selected for commit access, a metacommitter gives the new
-committer access to the SVN repository and the bugtracker. The architect is a
+committer access to the repository and the bugtracker. The architect is a
metacommitter, but other team members also hold this role.
=item Committer
View
28 docs/gettingstarted.pod
@@ -1,4 +1,4 @@
-# Copyright (C) 2001-2009, Parrot Foundation.
+# Copyright (C) 2001-2010, Parrot Foundation.
# $Id$
=head1 NAME
@@ -22,10 +22,10 @@ L<https://trac.parrot.org/parrot/wiki/NewParrotDeveloperGuide>.
=item *
-There is a web interface to the subversion repository, in case you just want to
+There is a web interface to the git repository, in case you just want to
browse the source.
-L<https://trac.parrot.org/parrot/browser>
+L<http://github.com/parrot/parrot>
=item *
@@ -36,16 +36,10 @@ L<http://www.parrot.org/release/current>
=item *
-An even better option is to use SVN, which gets you the very latest copy of the
+An even better option is to use git, which gets you the very latest copy of the
Parrot distribution. The procedure for this is:
- svn checkout https://svn.parrot.org/parrot/trunk parrot
-
-=item *
-
-If you're using git-svn, you should check out just the latest version. First:
-
-C<< git svn clone -s -r HEAD https://svn.parrot.org/parrot >>
+ git clone http://github.com/parrot/parrot
=back
@@ -64,7 +58,7 @@ some reasonable form of C<make>. To do this, follow these three easy steps.
=item 1
-C<cd> to your parrot directory and run C<Configure.pl> to create the makefile
+C<cd> to your parrot directory and run C<perl Configure.pl> to create the makefile
for your platform.
=item 2
@@ -175,16 +169,8 @@ helpful to subscribe and keep up on changes that people are making.
L<http://lists.parrot.org/mailman/listinfo/parrot-commits>
-=item * Parrot Commits NNTP Interface
-
-L<...>
-
-L<...>
-
=item * Commit List Archives, RSS
-L<...>
-
L<http://lists.parrot.org/pipermail/parrot-commits/>
=back
@@ -198,8 +184,6 @@ with real-time discussion. Visit the channel #parrot on the IRC
server L<irc.parrot.org>. Alternative IRC servers are
L<irc.rhizomatic.net> and L<irc.pobox.com>.
-
-
=head2 I've developed a patch. What should I do with it?
See F<docs/submissions.pod> for details.
View
2 docs/parrot.pod
@@ -136,7 +136,7 @@ See:
=item * L<https://trac.parrot.org/>
-=item * L<https://svn.parrot.org/>
+=item * L<http://github.com/parrot/parrot>
=back
View
5 docs/pdds/pdd00_pdd.pod
@@ -94,11 +94,6 @@ A short, general description of a specific part of the Parrot design. This may
be a particular subsystem (e.g. the garbage collector), or a more general
topic (e.g. basic Parrot datatypes).
-=item Version:
-
-Document version. Since Parrot is currently kept in a Subversion repository,
-the $$-delimited keyword "Revision" will do nicely.
-
=item Abstract:
A quick blurb explaining the purpose of the PDD.
View
79 docs/pdds/pdd07_codingstd.pod
@@ -498,81 +498,6 @@ the variables happen to have the same names.
You could hoist the C<int i;> outside the test, but then you'd have an
C<i> that's visible after it's used, which is confusing at best.
-=head3 Subversion Properties
-
-=head4 svn:ignore
-
-Sometimes new files will be created in the configuration and build process of
-Parrot. These files should not show up when checking the distribution with
-
- svn status
-
-or
-
- perl tools/dev/manicheck.pl
-
-The list of these ignore files can be set up with:
-
- svn propedit svn:ignore <PATH>
-
-In order to keep the two different checks synchronized,
-the MANIFEST and MANIFEST.SKIP files should be regenerated with:
-
- perl tools/dev/mk_manifest_and_skip.pl
-
-and the files then committed to the Parrot svn repository.
-
-=head4 svn:mime-type
-
-The C<svn:mime-type> property must be set to C<text/plain> for all test
-files, and may be set to C<text/plain> for other source code files in
-the repository. Using I<auto-props>, Subversion can automatically set
-this property for you on test files. To enable this option, add the
-following to your F<~/.subversion/config>:
-
- [miscellany]
- enable-auto-props = yes
- [auto-props]
- *.t = svn:mime-type=text/plain
-
-The F<t/distro/file_metadata.t> test checks that the files needing
-this property have it set.
-
-=head4 svn:keywords
-
-The C<svn:keywords> property should be set to:
-
- Author Date Id Revision
-
-on each file with a mime-type of C<text/plain>. Do this with the command:
-
- svn propset svn:keywords "Author Date Id Revision" <filename>
-
-The F<t/distro/file_metadata.t> test checks that the files needing
-this property have it set.
-
-=head4 svn:eol-style
-
-The C<svn:eol-style> property makes sure that whenever a file is checked out
-of subversion it has the correct end-of-line characters appropriate for
-the given platform. Therefore, most files should have their
-C<svn:eol-style> property set to C<native>. However, this is not true
-for all files. Some input files to tests (such as the C<*.input> and
-C<*.output> files for PIR tests) need to have C<LF> as their
-C<svn:eol-style> property. The current list of such files is described in
-F<t/distro/file_metadata.t>.
-
-Set the C<svn:eol-style> property to C<native> with the command:
-
- svn propset svn:eol-style "native" <filename>
-
-Set the C<svn:eol-style> property to C<LF> with the command:
-
- svn propset svn:eol-style "LF" <filename>
-
-The F<t/distro/file_metadata.t> test checks that the files needing
-this property have it set.
-
=head3 Naming Conventions
=over 4
@@ -821,10 +746,6 @@ The Pod documentation should follow the layout:
=over 4
-=item Version
-
-A SVN id string.
-
=item Title
=head1 Foo
View
7 docs/project/cage_cleaners_guide.pod
@@ -333,13 +333,6 @@ If neither, please report your findings so that everyone can decide what to do.
=head1 Handy configuration tips
-=head2 Subversion configuration and automatic properties
-
-There is an example C<.subversion/config> file in
-F<editor/subversion_config> which is useful in automatically setting the
-appropriate Subversion properties relevant to Parrot on addition of new
-files.
-
=head2 Displaying trailing whitespace in vim and emacs
=head3 Vim
View
2 docs/project/debian_packaging_guide.pod
@@ -38,7 +38,7 @@ directory should be named "parrot-<version>" (it will be by default).
Copy the debian/ directory from the Parrot source tree into the fresh tarball
extract.
- cp -r <path/to/parrot/svn>/ports/debian ~/deb/parrot/parrot-<version>/.
+ cp -r <path/to/parrot/git>/ports/debian ~/deb/parrot/parrot-<version>/.
Copy the original tarball into ~/deb/parrot, naming it
"parrot_<version>.orig.tar.gz" (note the "_" in place of dash).
View
102 docs/project/git_terminology.pod
@@ -0,0 +1,102 @@
+=head1 NAME
+
+docs/project/git_terminology.pod - Git Terminology
+
+=head1 DESCRIPTION
+
+This document describes terms that are used in F<docs/project/git_workflow.pod>
+and contains generally useful things to know about Git.
+
+=head1 INTRODUCTION
+
+Before learning any terminology, there are a few very basic things that
+should be understood about Git, which will provide a foundation for
+understanding anything else.
+
+A Git repository is a Directed Acyclic Graph (DAG), where each node in the
+graph is a commit, with zero or more parents. The first commit of a
+repository has zero parents, others have at least one parent. If a commit has
+more than one parent, that means it was the result of a merge.
+
+Each commit is uniquely identified by a SHA1 sum. You may refer to any commit
+by the first few characters of a SHA1 sum, as long as it is unique. If it is
+not unique, C<git> will complain loudly. Usually 6-7 characters of a SHA1 is
+sufficient, but this number increases as the number of commits in a repo
+grows.
+
+There are three distinct "places" in a Git repository, which are referred to
+as the index, the working copy, and the staging area. The index is the actual
+DAG, where all the history of the repo is stored. This lives in the .git
+directory of a repository. The "working copy" are the actual files on the
+filesystem. The staging area is where things that will be included in the
+next commit live. When you type C<git add foo>, you are adding the
+file/directory foo to the staging area. When you type C<git log> you are
+asking the index to show you a log of all commits. When you run a non-git
+command in a repo, such as C<rm foo>, you are modifying the working copy.
+
+The most important thing to learn when understanding a C<git> command is whether
+it operates on the index, working copy, staging area or a combination of the
+three. Also note that certain C<git> commands can operate on different areas
+when given different command-line options.
+
+=head1 HELPING YOURSELF
+
+Git comes with extensive documentation. To get the short help summary for a git
+command, do C<git cmd -h>. To see the manual for a git command, type C<git help
+cmd>, where "cmd" is the name of the command you want to look up.
+
+=head1 TERMS
+
+=head2 branch
+
+Noun. A symbolic name referring to a commit SHA1. The master branch is just a branch
+called master, it is not special in any way except that it is the default.
+
+Verb. To create a divergent history of commits from a given commit, branch or tag.
+
+=head2 clone
+
+Verb. The term used for copying a remote repo locally, which contains the entire
+history of the git repo being cloned.
+
+=head2 commit-ish, committish
+
+Noun. A general term for a way to describe a set of commits.
+
+=head2 rebase
+
+Verb. Update the local index with changes from a remote, then replay local changes,
+in order, on top of them.
+
+=head2 remote
+
+Noun. A remote is basically a URL with metadata that describes where changes are
+pushed/pulled from. A git repo may have any number of remotes. The default
+remote is where the repo was originally cloned from and it has the name
+"origin".
+
+=head2 repo
+
+Noun. Short for repository.
+
+=head2 SHA1
+
+Noun. Secure Hash Algorithm 1. Also called a SHA1 sum or SHA1 hash. Every git commit
+is uniquely identified by a SHA1. This is roughly similar to a Subversion
+Revision, but it is not an integer and does not increase linearly, because git
+commits can have any number of parents.
+
+=head2 topic branch
+
+Noun. Any branch that is not the master branch.
+
+=head1 SEE ALSO
+
+F<docs/project/git_workflow.pod>
+
+=cut
+
+__END__
+Local Variables:
+ fill-column:78
+End:
View
260 docs/project/git_workflow.pod
@@ -0,0 +1,260 @@
+# Copyright (C) 2008-2010, Parrot Foundation.
+# $Id$
+
+=head1 NAME
+
+docs/project/git_workflow.pod - How to use Git to work on Parrot
+
+=head1 DESCRIPTION
+
+To minimize the disruption of feature development on language and tool
+developers, all major changes to Parrot core take place in a branch. Ideally,
+branches are short-lived, and contain the smallest set of changes possible.
+It is also good practice to have "atomic" commits, in the sense that each
+commit does one thing, so that it makes it easier to accept/revert some
+things while keeping others. Git provides many powerful tools in the
+maintainence of branches. This document aims to provide everything a Parrot
+developer needs to know about Git to successfully create a branch, work on
+it, keep it in sync with changes on master and finally merge the branch.
+
+=head2 Cloning the Git Repository
+
+To get the full version history Parrot, which is called "cloning a repository",
+you will use the C<git clone> command. This will show how to clone the repo from
+L<http://github.com> :
+
+ git clone git://github.com/parrot/parrot.git
+
+If you have commit access to parrot.git, then you can use the read/write SSH
+protocol
+
+ git clone git@github.com:parrot/parrot.git
+
+If you are behind a firewall that will only let you do HTTP, you can use the
+HTTP protocol, but it is much slower and inefficient, so only use it if you
+must:
+
+ git clone http://github.com/parrot/parrot.git
+
+Cloning a git repo automatically makes the URL that you cloned from your
+default "remote", which is called "origin". What this means is that
+when you want to pull in new changes or push changes out in the future,
+"origin" is what will be used by default.
+
+=head2 Creating and Switching Branches
+
+To create a branch and check it out, use the C<git checkout -b> command.
+Please note that branches are first created locally, and then pushed
+to any number of remotes. A branch cannot be seen by anyone else
+until it is pushed to a remote.
+
+Current convention is to create branch names of the form username/foo.
+
+ git checkout -b username/foo
+
+You can also create a branch without checking it out:
+
+ git branch username/foo
+
+To checkout (or "switch to", as it is commonly referred to) the username/foo
+branch:
+
+ git checkout username/foo
+
+=head2 Pushing branches and tags
+
+If you want to push your local branch user/branch to origin:
+
+ git push origin user/branch
+
+Tags are not pushed by default. If you want to push your tags to origin:
+
+ git push origin --tags
+
+Since origin is the default remote, this is the same as
+
+ git push --tags
+
+=head2 Keeping branches updated
+
+To get the latest updates:
+
+ git fetch
+
+This copies the index from your default remote (origin) and saves it to your
+local index. This does not effect your working copy, so it doesn't matter
+what branch you are on when you run this command. To sync up your working
+copy, you can use C<git rebase>
+
+ git checkout master # Switch to the master branch
+ git rebase origin/master # rebase latest fetched changes onto master
+
+This is a common action, so there is also a simpler way to do it:
+
+ git pull --rebase
+
+Whenever you don't specify a remote or branch to a git command, they default
+to the remote called "origin" and the master branch, so the previous command
+means exactly the same as:
+
+ git pull --rebase origin master
+
+This is important to note when you are working with remotes other than origin,
+or other branches.
+
+=head2 How to commit
+
+Let's say you modified the file foo.c and added the file bar.c and you want to commit
+these changes. To add these changes to the staging area (the list of stuff
+that will be included in your next commit) :
+
+ git add foo.c bar.c
+
+The command C<git add> is not only for adding new files, just keep that in mind.
+It tells git "add the state of these files to my staging area."
+
+Now for actually creating your commit! Since Git is a distributed version control
+system, committing code is seperate from sending your changes to a remote server.
+Keep this in mind if you are used to Subversion or similar VCS's, where committing
+and sending changes are tied together.
+
+ git commit -m "This is an awesome and detailed commit message"
+
+If you do not give the -m option to C<git commit>, it will open your $EDITOR
+and give you metadata which will help you write your commit message,
+such as which files changed and if conflicts happened. Only lines that do
+not begin with a # will be in your commit message.
+
+Commit messages consist of a one line "short message" and an optional long
+message that can be as long as you like. There must be an empty line between
+the short message and the long message. It is often a good practice to keep the
+first line of a commit message relatively short, around 50 characters. This
+allows for tools to succinctly display one-line commit messages with metadata.
+It is good practice to describe *why* something was done in the long message,
+in addition to what was done.
+
+=head2 Maintaining a Branch
+
+To update your local git index from origin:
+
+ git fetch
+
+If you are following multiple remotes, you can fetch updates from all of them with
+
+ git fetch --all
+
+Note that this command requires a recent (1.7.x.x) version of git.
+
+The command C<git fetch> only modifies the index, not your working copy or staging
+area. To update your working copy of the branch bobby/tables
+
+ git checkout bobby/tables # make sure we are on the branch
+ git rebase origin/bobby/tables # get the latest sql injections
+
+If you have a topic branch and want to pick up the most recent changes in master
+since the topic branch diverged, you can merge the master branch into the topic
+branch. In this case, we assume the topic branch is called parrot/beak:
+
+ git checkout parrot/beak # make sure we are on the branch
+ git merge master # merge master into parrot/beak
+
+This same pattern can be followed for merging any branch into another
+branch.
+
+=head2 Preparing to Merge a Branch
+
+Post to parrot-dev@lists.parrot.org letting people know that you're about to
+merge a branch.
+
+=over
+
+=item 1
+
+Ask people to submit test results for their language, tool, or platform. They
+can submit results to Smolder by typing "make smoke" on the relevant branch. If
+you don't hear back from people, it doesn't mean they ran the tests and found
+no problems, it means they didn't bother testing the branch. If you need
+feedback on a particular language or platform, follow up with the person
+responsible until you hear an explicit "Yes, it's working" answer.
+
+=item 2
+
+Let people know what tests you ran, so they can determine if you didn't run
+the tests for their language or tool (or, didn't run I<all> the tests for
+their language or tool if they have some unusual testing configuration).
+
+=item 3
+
+Mention any significant feature changes in the branch that you particularly
+want tested.
+
+=back
+
+=head2 Merging a Branch
+
+When you're ready to merge your changes back into master, use the C<git merge>
+command. First, make sure you are on the master branch with
+
+ git checkout master
+
+Now, to merge the branch user/foo into master:
+
+ git merge user/foo
+
+If the same part of the same file has been modified in master and the branch
+user/foo, you will get a conflict. If you get a conflict, then you need to edit
+each file with a conflict, fix the conflict, delete the conflict markers, C<git
+add> each conflicted file and then finally commit the result. You may find it
+useful to type C<git commit> with no commit message argument (-m), so your
+$EDITOR will be opened and a default commit message of "Merged branch user/foo
+into master" with a list of conflicted files will be present, which can be left
+alone or additional information can be added.
+
+At this point you should run the test suite on the merged branch, and fix
+any failures if possible. If these problems cannot be resolved, then
+the results of the merge should not be pushed back to master on origin.
+You may want to push a topic branch to allow other people to help:
+
+ git checkout -b user/foo_in_master
+ git push origin user/foo_in_master
+
+You can now mention the problems you ran into to parrot-dev or #parrot
+and mention the branch.
+
+=head2 Announcing a Merge
+
+Send a message to parrot-dev@lists.parrot.org letting people know that your
+branch has been merged. Include a detailed list of changes made in the branch
+(you may want to keep this list as you work). Particularly note any added,
+removed, or changed opcodes, changes to PIR syntax or conventions, and changes
+in the C interface.
+
+If there was a specific language, tool, or platform that you wanted tested
+before merging but couldn't get any response from the responsible person, you
+may want to include some warning in the announcement that you weren't able to
+test that piece fully.
+
+=head2 Deleting a Branch
+
+After merging a branch, you will have a local copy of the merged branch, as well
+as a copy of the branch on your remote. To remove the local branch:
+
+ git branch -d user/foo
+
+To remove the remote branch user/foo on the remote origin :
+
+ git push origin :user/foo
+
+This follows the general pattern of
+
+ git push origin local_branch_name:remote_branch_name
+
+When local_branch_name is empty, you are pushing "nothing" to the remote branch,
+which deletes it.
+
+=cut
+
+__END__
+Local Variables:
+ fill-column:78
+End:
View
27 docs/project/release_manager_guide.pod
@@ -53,9 +53,17 @@ L<http://en.wikipedia.org/wiki/List_of_parrots>.
=item 1.
The day of the release has come.
-Make sure you're up to date:
+Make sure you have the most recent version of the master branch:
- $ svn update
+ $ git checkout master && git pull --rebase
+
+Also be sure you do not have any local commits that have not yet
+been pushed out and tested thoroughly. You can check for this with
+
+ $ git log ..origin/master
+
+If there is no output from that command, then your local master
+and the master on origin are in sync.
=item 2.
@@ -168,11 +176,13 @@ harnesses are being run.
When all is well, then commit your changes:
- svn diff | more
- svn commit
+ $ git diff
+ $ git add file1 file2 ...
+ $ git commit -m "awesome and informative commit message"
+
+Note the SHA1 from this commit. You will need it later in step 7.
-Write down the revision number from this commit. You will need it later in
-step 7.
+ $ git revparse master > SHA1_TO_REMEMBER
=item 4.
@@ -205,9 +215,8 @@ Verify that the version is correct and doesn't contain the suffix C<devel>:
Tag the release as "RELEASE_a_b_c", where a.b.c is the version number.
Specify the revision number generated in step 3, above.
- $ export SVNPARROT=https://svn.parrot.org/parrot
- $ svn copy -r <REV> -m "tagged release a.b.c" \
- $SVNPARROT/trunk $SVNPARROT/tags/RELEASE_a_b_c
+ $ git tag RELEASE_a_b_c
+ $ git push --tags
=item 8.
View
14 docs/project/ticket_triaging.pod
@@ -106,7 +106,7 @@ This way you will receive further correspondence about the ticket.
=item add the patch author to F<CREDITS> or update the author's entry
=item add correspondence to the ticket stating that the patch was applied.
-Include the SVN revision number in your response.
+Include the commit SHA1 in your response.
=item make sure that the ticket's 'Tag' includes 'Patch'
@@ -130,7 +130,7 @@ from the requestor. Change the status to C<stalled>.
If it's a [PATCH] ticket, it's possible that the patch was applied but the
ticket/patch status was never changed. Also, not all list traffic regarding a
-ticket ends up in the tracker. Look at the SVN repo to attempt to determine if
+ticket ends up in the tracker. Look at the git repo to attempt to determine if
the ticket was resolved.
=item Review of stalled tickets
@@ -270,7 +270,7 @@ think that their ticket was unimportant or ignored.
Hi,
- Can you retest for this ticket with the latest sources from SVN and confirm
+ Can you retest for this ticket with the latest sources from git and confirm
that this still an open issue?
Thanks,
@@ -281,7 +281,7 @@ or
Hi,
- Would you mind retesting with the latest sources from SVN?
+ Would you mind retesting with the latest sources from git?
Thanks,
@@ -291,7 +291,7 @@ or
Hi,
- Can you resubmit this patch against SVN trunk?
+ Can you resubmit this patch against git master?
Thanks,
@@ -324,9 +324,7 @@ or
-J
-=head1 SVN USAGE TIPS
-
-=head2 Commit messages
+=head1 TIPS FOR WRITING COMMIT MESSAGES
=over 4
View
4 docs/project/ubuntu_packaging_guide.pod
@@ -46,13 +46,13 @@ F<ports/ubuntu/changelog>, preserving chronological order.
Copy the F<ports/debian/> directory from the Parrot source tree into the fresh
tarball extract.
- cp -r <path/to/parrot/svn>/ports/debian ~/udeb/parrot/parrot-[version]/.
+ cp -r <path/to/parrot/git>/ports/debian ~/udeb/parrot/parrot-[version]/.
Then copy the unique Ubuntu files (F<changelog> and F<control.in>) from
F<ports/ubuntu/> into the new F<debian/> directory.
- cp <path/to/parrot/svn>/ports/ubuntu/* ~/udeb/parrot/parrot-[version]/debian/.
+ cp <path/to/parrot/git>/ports/ubuntu/* ~/udeb/parrot/parrot-[version]/debian/.
=item 4.
View
29 docs/submissions.pod
@@ -46,14 +46,13 @@ for whatever the distribution's parent directory is called on your machine.
=over
-=item C<svn>
+=item C<git>
-If you are working with a checked out copy of parrot then please generate
-your patch with C<svn diff>.
+If you are working with a git repository of parrot then please generate
+your patch with C<git diff>.
cd parrot
- svn status
- svn diff > my_contribution.patch
+ git diff > my_contribution.patch
=item Single C<diff>
@@ -75,7 +74,7 @@ recursive C<diff> on the two directories to create your patch. The C<diff>
should be created in F<workingdir>.
cd workingdir
- diff -ur --exclude='.svn' parrot parrot.new > docs.patch
+ diff -ur --exclude='.git' parrot parrot.new > docs.patch
Mac OS X users should also specify C<--exclude=.DS_Store>.
@@ -148,18 +147,18 @@ file(s).
=head1 Applying Patches
You may wish to apply a patch submitted by someone else before the patch is
-incorporated into SVN.
+incorporated into git
-For single C<diff> patches or C<svn> patches, copy the patch file to
+For single C<diff> patches or C<git> patches, copy the patch file to
F<parrot>, and run:
cd parrot
- patch -p0 < some.patch
+ git apply some.patch
For recursive C<diff> patches, copy the patch file to F<workingdir>, and run:
cd workingdir
- patch -p0 < some.patch
+ git apply some.patch
In order to be on the safe side run 'make test' before actually committing
the changes.
@@ -169,16 +168,12 @@ the changes.
Sometimes new files will be created in the configuration and build process of
Parrot. These files should not show up when checking the distribution with
- svn status
+ git status
or
perl tools/dev/manicheck.pl
-The list of these ignore files can be set up with:
-
- svn propedit svn:ignore <PATH>
-
In order to keep the two different checks synchronized,
the MANIFEST and MANIFEST.SKIP file should be regenerated with:
@@ -256,10 +251,10 @@ for the new ticket and can check on the progress of your submission there.
This identifier should be used in all correspondence concerning the submission.
Everyone on Trac sees the submission and can comment on it. A developer with
-SVN commit authority can commit it to SVN once it is clear that it is the
+git commit priveledges can commit it to git once it is clear that it is the
right thing to do.
-However developers with SVN commit authority may not commit your changes
+However developers with commit priveledges may not commit your changes
immediately if they are large or complex, as we need time for peer review.
A list of active tickets can be found here:
View
61 editor/subversion_config
@@ -1,61 +0,0 @@
-### $Id$
-
-### This file configures various client-side behaviors for Subversion for
-### use with Parrot.
-### Append it to your current ~/.subversion/config or update your current
-### version of the file to include the following options.
-
-### Section for configuring miscelleneous Subversion options.
-[miscellany]
-### Set enable-auto-props to 'yes' to enable automatic properties
-### for 'svn add' and 'svn import', it defaults to 'no'.
-### Automatic properties are defined in the section 'auto-props'.
-enable-auto-props = yes
-
-### Section for configuring automatic properties.
-### The format of the entries is:
-### file-name-pattern = propname[=value][;propname[=value]...]
-### The file-name-pattern can contain wildcards (such as '*' and
-### '?'). All entries which match will be applied to the file.
-### Note that auto-props functionality must be enabled, which
-### is typically done by setting the 'enable-auto-props' option.
-[auto-props]
-# C
-*.c = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.h = svn:eol-style=native; svn:keywords=Author Date Id Revision
-# Perl
-*.pl = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.pm = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.pod = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.t = svn:eol-style=native; svn:mime-type=text/plain; svn:keywords=Author Date Id Revision
-# Parrot
-*.pasm = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.pir = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.pg = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.pmc = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.ops = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.tg = svn:eol-style=native; svn:keywords=Author Date Id Revision
-# Parrot languages
-*.bas = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.lua = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.m4 = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.jako = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.java = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.p6 = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.py = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.rb = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.tap = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.urm = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.z3 = svn:eol-style=native; svn:keywords=Author Date Id Revision
-# Flex/yacc
-*.l = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.y = svn:eol-style=native; svn:keywords=Author Date Id Revision
-# General
-*.css = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.html = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.in = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.txt = svn:eol-style=native; svn:keywords=Author Date Id Revision
-*.xml = svn:eol-style=native; svn:keywords=Author Date Id Revision
-Makefile = svn:eol-style=native; svn:keywords=Author Date Id Revision
-README = svn:eol-style=native; svn:keywords=Author Date Id Revision
-

0 comments on commit 8beef6b

Please sign in to comment.