I am looking for any available docs that will help me learn the layout
of the jgit code base.
In the ideal world here is what would help newbies get productive with
the project quickly:
1. Have a clear one line description available in the javadocs for each
package.
2. Have a clear one line description available in javadocs for each
class in each package.
3. Have a clear one line description available in javadocs for each
method in each class.
I would gladly do this and contribute the changes back but its a chicken
and egg situation since I do not know the code base.
I realize its a lot to ask but would anyone familiar with code base
volunteer to do at least (1) above?
At minimum could anyone tell me what packages and classes to look at in
order to make changes to jgit so it uses a database instead of
filesystem to references.
Lastly, where can I find information on the structure of the .git directory?
Thanks for your help.
Kyle Moffett wrote:
On Thu, Nov 13, 2008 at 3:27 PM, Farrukh Najmi
<farrukh@xxxxxxxxxxxxxxxxxxxxx> wrote:
The problem I am trying to solve is this. In my service I need to store
metadata in a relational db and content in git such that both either commit
or not in a single transaction. If one commits and the other does not that
is a serious integrity issue. Seems to me, two phase commit would be the
right solution for that in the long run. This what JDBC + JMS topologies do.
That's really easy! First tweak jgit so that *instead* of using
.git/refs, it uses your database to store references and exports them
on a routine basis to .git/refs for debugging purposes. Then, for
each database update:
(1) Start transaction
(2) Commit the change to GIT (adds ref update to the transaction)
(3) Make other metadata updates
(4) Commit transaction
Then set up periodic garbage collection and you're done! If the
transaction is aborted, there will simply be a bunch of random loose
objects in the git repository, which will be cleaned up the next time
you garbage collect. The ref update will be atomic and conditional
with the rest of the transaction, and in git the *only* part that
really matters for atomicity is the ref.
Cheers,
Kyle Moffett
--
Regards,
Farrukh Najmi
Web: http://www.wellfleetsoftware.com
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
