Open GoogleCodeExporter opened 9 years ago
Also it would be nice to get some basic PHPUnit testing going on - have you
looked into that at all? I'm not sure exactly how you would test PDF output,
but I bet a lot of the internal components and HTML/CSS parsing could be tested
fairly easily.
One more -1 for google code - It seems I don't even get email notifications to
these bugs, I didn't see you replied to the comment I made on #543.
Original comment by adr...@crescendo.net.nz
on 11 Nov 2012 at 5:14
Hello, I'm seriously considering a migration to Github. I'm currently learing
by migrating locally the whole SVN repository to a Github one, and it works
like a charm.
I'm also aware that DOMPDF uses old habits, like constants for configuration,
weird file naming, self defined autoloader, no composer/packagist, SVN and PHP
5.1.
I currently don't have time to handle all this, and migrating to Github to get
all this in a far easier way is something I should definitely do. So I'm trying
to do this now.
As of PHP 5.3 compatibility, maybe we should wait the 0.6 release to get all
this, to have a stable release for people (like me) who need it in old PHP
installations. I'm more than conscious that PHP 5.1 / 5.2 are really old, so I
completely understand the need to drop support for them.
And about PHPUnit, I personnaly prefer Atoum, a French still international and
very active unit testing system. (https://github.com/mageekguy/atoum/) It's
docs are currently being written.
Original comment by fabien.menager
on 11 Nov 2012 at 9:40
Awesome! Re the move to github, it would make sense to just fork the existing
shadowhand repo rather than starting a new one (since they have done all the
work importing from svn already, and other people have already forked it). Then
clean up the folder naming scheme, for example:
https://github.com/adrianmacneil/dompdf
If you're looking to add some structure to your git branches, check out git
flow (http://nvie.com/posts/a-successful-git-branching-model/) and the git
extension for it (https://github.com/nvie/gitflow).
If you give me access to your github repo I'd be happy to spend some time
fixing the package layout (remove top level dompdf dir), and migrating/cleaning
up existing issues from google code.
As you say, probably better to keep the 0.6 branch going with PHP 5.1 support,
and start a new branch for PHP 5.3 which breaks backwards compatibility.
Original comment by adr...@crescendo.net.nz
on 11 Nov 2012 at 11:32
Oh and I hadn't heard of Atoum, will check it out. But since this is a public
project, it would probably be better to stick with PHPUnit since pretty much
one uses & is familiar with it, and this lowers the barriers of entry for
contributions. Not saying that Atoum might not be great for private/internal
projects, but if you want to encourage people to contribute then it's good to
use industry standard tools.
With the github repo - consider creating a github organization (free), so it's
clear this is the official repo. For example, the repo URL would then be
https://github.com/dompdf/dompdf
Original comment by adr...@crescendo.net.nz
on 11 Nov 2012 at 11:36
It looks like file history didn't follow the project layout fix on your repo,
is there a way to change this?
The few forks of shadowhand's repo are all about fixing dependencies and git
ignore, so I think we can create our own, and then after this, people will fork
ours.
We'll see with Brian for the unit tests. IMHO, it would be a shame if we don't
use tools if they are not industry standards, while they are better.
Your URL works now! I created the repo as mine, then transferred ownership
after creating the dompdf organization.
Original comment by fabien.menager
on 12 Nov 2012 at 8:59
Alright I sorted it all out. Take a look at
https://github.com/adrianmacneil/dompdf (btw it's always best to completely
delete github repo and recreate it if you want a clean slate).
The winning command was:
git svn clone http://dompdf.googlecode.com/svn/ dompdf --trunk=trunk/dompdf
--tags=tags/*/dompdf --branches=branches/*/dompdf
Followed by some manual tagging, then pushing all branches and tags to github.
Feel free to just clone/fork my one if you can't be bothered. Not sure how
familiar you are with git, but note that if you want to clone the whole repo
manually (without using github fork button), you need to pull down each branch
individually, then push it back up to your new repo.
Also git handles renames pretty differently to svn, it doesn't usually show
history after a rename, so it's probably not going to matter once you move to
PSR0 file naming scheme anyway. But at least it's nice to keep the existing
history.
Original comment by adr...@crescendo.net.nz
on 12 Nov 2012 at 11:18
One more thing - in an ideal world you would run the whole thing through git
filter-branch and fix your commits so they have your correct email address
(therefore github matches it to your username). Currently it just has a name
for all the commits. But it's not a huge deal.
Original comment by adr...@crescendo.net.nz
on 12 Nov 2012 at 11:20
Thanks for the trick ! I actually used "git svn" too, but with different
--trunk, --tags and --branches values. I'll give a try with your command
tonight, i'll reset the current repository.
I used a users.txt file, with the name of all the committers to keep the links
to github accounts.
Original comment by fabien.menager
on 12 Nov 2012 at 1:39
I found a tool that could be helpful to import the issue tracker :
https://github.com/dave0/gcode-issue-import
Did you already use it ?
Original comment by fabien.menager
on 12 Nov 2012 at 9:30
Everything is in place in the new repository, except for one thing, I did two
commit/push
https://github.com/dompdf/dompdf/commit/284b6e4a2ac36334ea04534f45d26a60db536f6f
https://github.com/dompdf/dompdf/commit/4529d5b7be54eec47e35348191252d2ad2412aa5
But they don't appear in the source or the history, what did I don't do ?
Original comment by fabien.menager
on 12 Nov 2012 at 10:32
Nevermind, the web UI took more time to show it than I expected.
Original comment by fabien.menager
on 12 Nov 2012 at 10:37
Awesome! I notice you haven't imported the branches and tags, did you want to
do that? If you have them locally you can push the tags with git push --tags,
and the branches you must push one at a time.
Original comment by adr...@crescendo.net.nz
on 12 Nov 2012 at 10:44
Original comment by eclecticgeek
on 24 May 2013 at 3:00
Original issue reported on code.google.com by
adr...@crescendo.net.nz
on 11 Nov 2012 at 5:06