I have two llvm projects in different stages of execution:
1) Parallel "make check".
Modelled after the successful clang "make test -jX" experiment, I am
now bold enough to sink my teeth into the LLVM test suite.
I have a prototype implementation, along the same lines, ready.
2) <class Use> size reduction.
After some conversation with Chris I think we are ready for a
16 -> 12 byte size reduction of the Use class. There are some
collateral improvements too. This project is in its conceptual phase.
To drive forward these projects I prefer to work on branches. So I
apply for a branches/ggreif/... hierarchy in the repository. I shall make
it easy to use "svn switch ..." for the relevant directories for anybody
who wants to test my work.
After I feel that all is stable and nice, I will make a diff for review and
get back to this list. After successful review and rework, I shall merge
back to main.
1) Parallel "make check".
Modelled after the successful clang "make test -jX" experiment, I am
now bold enough to sink my teeth into the LLVM test suite.
I have a prototype implementation, along the same lines, ready.
2) <class Use> size reduction.
After some conversation with Chris I think we are ready for a
16 -> 12 byte size reduction of the Use class. There are some
collateral improvements too. This project is in its conceptual phase.
Yay.
To drive forward these projects I prefer to work on branches. So I
apply for a branches/ggreif/... hierarchy in the repository. I shall
make
it easy to use "svn switch ..." for the relevant directories for anybody
who wants to test my work.
Sure, go for it.
After I feel that all is stable and nice, I will make a diff for review and get back to this list. After successful review and rework, I shall merge back to main.
Sounds good. Just for sake of making patch review simpler, please make the proposed patches as small and independent as possible.
2) <class Use> size reduction.
After some conversation with Chris I think we are ready for a
16 -> 12 byte size reduction of the Use class. There are some
collateral improvements too. This project is in its conceptual phase.
Could you explain this in detail?
I want to be sure that you're considering both the case where Use is embedded in a User and where it isn't, such as when it's malloc'd.
To drive forward these projects I prefer to work on branches.
So I apply for a branches/ggreif/... hierarchy in the
repository. I shall make
it easy to use "svn switch ..." for the relevant directories
for anybody who wants to test my work.
I think that this might not generally be known, but you can
use "git" as your SCM/DSCM and have lot's of local, fast and
cheap branches ... and yet you can commit/update to/from an svn
repository.
This clones the names repository with revision 101 ("-r101") and
a standard trunk/ branches/ tags/ layout ("-s").
$ cd proj
$ git checkout -b test
This creates a test branch and checks it out. This is very fast.
Way faster than "svn switch" ... and you don't have to remember
the different URLs but just use a simple name.
Now edit. Then
$ git commit -a
to check your local change in. You can have as many local
branches as you want and, once the branch is created, you can
switch very fast between them using "git checkout master", "git
checkout test". You can even stash away uncommitted stuff in a
hurry (without committing it) with "git stash", see "git
stash --help". Once you're done, send your commits back to svn:
$ git svn dcommit
Now the subversion users will have your commits as well.
