maybe wroot is talking about this: http://fisheye.igniterealtime.org/graph/spark
doesn’t show recent commits… not sure if it’s supposed to…
No, i’m using http://fisheye.igniterealtime.org/changelog/spark?view=all&max=30&RSS=true
I want to have a per project feeds. This one is not showing latest commits in feedly or in Firefox live bookmarks.
I love Feedly
SO … did this happen on 31 March? I have an implementation for OF-714 ready to commit, and need to know if I can still use the SVN repository. Guess I’ll give it a go and see what happens …
Tom, Sorry about the confusion, the switch will probably be sometime later this week / weekend.
Thanks, Daryl. I assume later we’ll have same link for openfiregit?
The ‘SPARK’ Fisheye project was still connected with Spark’s SVN repository, I changed it to Spark’s git repository and the latest git commits appear now.
I would suspect so
OK - thanks for the update. I applied my changes to the SVN trunk.
Openfire’s repository has been migrated to git. The SVN is read-only now.
You can access Openfire’s git repository under: https://github.com/igniterealtime/Openfire
I hope that there where no types or other errors when maping the usernames. But if there is something wrong, please notify us. Although it’s not considered bad practice, we still could rewrite the published commits (but it should be avoided when possible).
I have migrated my NetBeans projects to Git clones (Spark and Openfire). Also switched my RSS to Fisheye Git feeds. Though Openfire’s clone took more than 10 minutes to complete and no wonder. It is 3 times heavier than my SVN clone was. Whopping 740 MB… Is it because of all these branches in there? I was cloning master*, because i don’t know much about Git and let the NetBeans decide As a plus NetBeans is taking less time to scan the projects on startup and build process is a bit faster. Also SVN copy stopped working for me a while ago because of bouncycasttle errors.
Another thing is when pointing a project to Git clone, NetBeans complained about compiled classes in there, so i let it delete them. Building works and Openfire starts, so i suppose there is no harm
openfire’s git repo will need a .gitignore and .gitattributes (plus LF normalization done) to get the repo ready for new commits and what-not. if nobody else wants that task, I can take care of both sometime this week.
@wroot – yes, cloning the repo will give you all of the remote repo’s branches (you can do: “git branch -a” to view them all and “git checkout <branch_name>” or “git checkout tags/<tag_name>” to get a specifc branch or tag (don’t konw the netbeans equivilent commands, sorry). I’d imagine working from the master branch is fine.
the git conversion + branches and tags (and most likely the history of each binary) probably bloated the repo size. removing the binaries (all the libs and stuff) at somepoint will drastically reduce that size.
not sure what netbeans means… do you know which files it complained about?
NetBeans shows all the tags and i could select say 3.9.0, but i thought selecting master* would be safer
NetBeans didn’t mention which classes it wanted to delete, so don’t know what exactly it deleted. So dar so good.
It is 3 times heavier than my SVN clone was.
No, it’s not. There is no such thing as a “SVN clone”, as it’s a centralized version control system. Users only checkout the latest revision as their working copy. The git equivalent to a SVN checkout would be a shallow clone. The quivalent of a git clone in SVN would be a dump of the SVN repository.
As git is decentralized, user always clone the complete development history at first, and the merge new commits into their local branch (or rebase on top of it).
Openfires git repository is ~ 1 GiB in size. This is similar to what it takes as SVN repository, but in fact, it’s less because git re-uses objects with the same SHA1, i.e. files with the same content from different commits/branches are only saved once. IIRC SVN doesn’t do this.
Some voices already said that we should strip some old binaries out of the repo. I can’t stress it enough that I don’t think that this is necessary. Disk space is cheap those days and so is bandwith. The initial clone of Openfires git repository may take a while, but all further pulls are incremental and, if they don’t contain big binaries, very fast.
What’s really important is that some one steps up and migrates Openfires build system to maven/gradle so that the binaries in form of third party libraries can be removed (if possible).
If you are interested in doing this, just join the official igniterealtime MUC: open_chat@conference.igniterealtime.org
Do you know, what happens to the maven-externalsbased branch?
I just toyed around a little bit with the new git repo and switched to the maven branch, but it only includes the pom.xml file basically.
In svn it used to reference the trunk source code. Can this be done in git, too?
openfire’s git repo will need a .gitignore and .gitattributes (plus LF normalization done) to get the repo ready for new commits and what-not. if nobody else wants that task, I can take care of both sometime this week.
A gitignore is certainly helpful. I am unsure about the LF normalization, as I see nobody enforcing it. Which means that after it hass been done, there will likely again some commits with CR/LF newlines. I would defer it until Openfire’s build system enforces LF newlines, e.g. with checkstyle.
FYI - as a part of my first commit/sync (to fix OF-114), I also included the .gitignore file for work/ and target/.
Another noob question I see new commits on Fisheye. But i suppose only Tom’s commit was “approved” and 3 other commits by Christian Shudt are not in the main source yet (master)? To sync only the changes approved to the main source should i Pull (Fetch) only the master branch? After i change something in my local source, how can i revert to the latest official source.
I’m not planning developing. I need to occasionally test a patch against the latest official source code. So i want to be able to get the latest “revision”, apply a patch, compile, test, revert changes so i can apply the next patch. What could be the flow for this in Git? I will find commands for this in NetBeans (hopefully).
looks like Christan’s are in there, Tom’s is more recent and maybe that’s what you are seeing? (you can use “git log” to view all the commits, their hashes (SHA-1) and their commit messages)
Pull vs Fetch:
Basic high level gist – Pull is a shortcut for Fetch + Merge. It downloads the latest changes from the remote repo and syncs them into your local working copy automatically and without review. Fetch will get the latest changes, but it sort of “stages” them for you in a local copy of the remote branch, waiting for your review and merge into your working copy.
For your purposes, Pull is probably what you want.
One possible workflow (in git cmd line, I don’t konw the netbeans equivilent, sorry!):
-
Clone repo (git clone https://github.com/IgniteRealtime/Spark.git)
-
Make a new local branch, from which you will apply your patches and test
(git checkout -b someCoolBranchName)
-
Apply your patch (there’s a few ways, depending on the format of the patch, see below)
-
Build and test
Next step can happen a few ways:
5-1) Stash your changes (so they are saved for later) and switch back to the master branch and re-sync with the remote master
git add . (or, git add /path/to/the/file) (adds files to your changeset)
git stash
A) or you can commit your changes if you are happy and want to keep them
git add . (or, git add /path/to/the/file)
git commit -m “your message about this commit”
B) or you can stash your changes, change back to another branch, and delete this testing branch
git add . (or, git add /path/to/the/file)
git stash
git checkout master (or name of another branch)
git branch -D someCoolBranchName
OR
5-2) Reset your local branch back to the last commit (before you started making changes)
git reset --hard
- Checkout (switch back) to your local master branch (git checkout master)
(Optional) Delete your testing branch:
git branch -D someCoolBranchName
(you can use “git branch -a” to see all branches, local and remote, this command will not accidentally delete a remote branch, you would have to push back to the repo to delete it)
-
Re-sync with the remote master, back down into your local master (git pull origin master)
-
Rinse - wash - and repeat
Few notes:
You can have as many local branches as you desire. They do not have to be present/created on the remote repo (github). They can “live” in your local repo forever if you wanted.
Any commit on github can be downloaded as a unified-diff/patch file by appending “.diff” or “.patch” to the end of the URL
https://github.com/igniterealtime/Openfire/commit/6e321fab6f7feac04606585cb3ceeb 6a8a46503e
to
https://github.com/igniterealtime/Openfire/commit/6e321fab6f7feac04606585cb3ceeb 6a8a46503e.patch
Depending on if it’s a unified-diff/patch file, or a git-formatted patch, you can apply them like:
patch -p0 --ignore-whitespace < patchfile.patch (unified-diff/patch file)
git apply --ignore-whitespace --ignore-space-change patchfile.patch (unified-diff/patch file and git formatted patch)
– “git apply” has a lot of cmd line flags that can be used with it to do lots of stuff, worth looking into.
Notes on Stashing:
http://gitready.com/beginner/2009/01/10/stashing-your-changes.html
http://git-scm.com/book/en/Git-Tools-Stashing
I just threw a bunch out there, tried not to be confusing! Again, I"m not familiar with the workflow while using netbeans, but most of this should have something similar. Maybe somebody else will share a workflow specific to working through an IDE for most of this.