plans are nice, but what then?

[Adam Heath-2]

Tim Ruppert wrote:
> That's a pretty interesting option and I'm sure one that you've put
> forward many times by now.  Is this something that can be supported by
> the ASF infrastructure or is that something we'd have to provide / do
> differently on top of the existing workflow to put into place?  I have
> to admit to reading a bit here and there about GIT, but not knowing it
> as well as other workflows.

I've been using git with ofbiz exclusively now for about one month.
All commits I've done recently have been thru "git svn."  I've used
git for almost a year.  It's faster than svn/svk(I've used both with
ofbiz).  For another project, it beats mercurial as well(except when
throwing a 40G repo at it, but only in certain cases).

History rewriting is wonderful.  Local branching is heavenly.  Local
copy of the entire ofbiz history is extremely cool.

There are plenty of existing docs out there that talk about how to use
 a central svn repo, but git locally.  You can git svn clone to your
laptop, walk around, grab a coffe, sit in a hotel lobby, commit lots
of changes, then reconnect back in your room at night and send all
your separate, *individual* changes.

Some may even remember last year at ApacheCon where I was using
mercurial+ofbiz/svn.

[David E. Jones-2]

Well, there's the apology you requested Adam: 'reconciling _both_  
"attacks"'

-David


On Oct 22, 2009, at 3:25 PM, Tim Ruppert wrote:

> Just so everyone is on the up and up, Hans and I are offline  
> reconciling _both_ "attacks" and will figure a way forward.  Thanks  
> for the help and the concern.
>
> Cheers,
> Ruppert
>
> On Oct 22, 2009, at 3:19 PM, Adam Heath wrote:
>
>> David E Jones wrote:
>>> I am saddened by the tone of some recent messages to you from Tim  
>>> and
>>> certain others at Hotwax, and I'm glad you are stepping up and
>>> responding well and being a peacemaker to help hold together the
>>> community that drives this project.
>>
>> I would almost go so far as to say Tim needs to actually apologize to
>> Hans; Tim's email was *that* bad.
>>
>

[Adam Heath-2]

Tim Ruppert wrote:
> Just so everyone is on the up and up, Hans and I are offline reconciling
> _both_ "attacks" and will figure a way forward.  Thanks for the help and
> the concern.

That's just it, I only saw one attack. :|

[David E. Jones-2]

On Oct 22, 2009, at 3:15 PM, Adam Heath wrote:

> Tim Ruppert wrote:
>> First of all, company based attacks will not be tolerated my friend -
>> please stop it, it makes you look bad and continues to erode faith.
>> This is me coming after you for your carelessness, has nothing to do
>> with my company, so feel free to remember that before you slop this  
>> up
>> here.  But if you'd like to talk about contributions and what _we've_
>> been doing, here you go.
>
> Huh?  What?  Come again?  Whatcha talking about Willis?
>
> Hans did *NOTHING* wrong with his email.  Absolutely *NOTHING*.  I
> suggest you take your head of out your ass, and stop being a bitch.
>
> ps: If you think my response is inappropriate, it's just as
> inappropriate as yours was to Hans, with no basis at all.

While I agree with you here Adam, and while I don't think you're  
response is inappropriate, I do think it would be good to tone it down  
a bit. No one should be using ad-hominem attacks, not even to other ad-
hominem attacks.

The thing that bothered me the most about Tim's message was using the  
false logic of the ad-hominem argument. It's an approach that tends to  
stop discussion and also breaks down community relationships. It's  
offensive and in an intelligent group like this that isn't so easily  
fooled or influenced it tends to weaken the arguments and position of  
the person using it. So, on that account... your response is accurate,  
if not entirely precise... ;)

Anyway, thanks for responding. I too hope that we can keep things  
friendly, or at least respectful, as there is a lot going on right now  
in the project, and it's also a time where a lot of us are under  
additional stress due to opportunities disappearing faster than  
obligations.

-David

[David E. Jones-2]

On Oct 22, 2009, at 3:26 PM, Adam Heath wrote:

> Tim Ruppert wrote:
>> That's a pretty interesting option and I'm sure one that you've put
>> forward many times by now.  Is this something that can be supported  
>> by
>> the ASF infrastructure or is that something we'd have to provide / do
>> differently on top of the existing workflow to put into place?  I  
>> have
>> to admit to reading a bit here and there about GIT, but not knowing  
>> it
>> as well as other workflows.
>
> I've been using git with ofbiz exclusively now for about one month.
> All commits I've done recently have been thru "git svn."  I've used
> git for almost a year.  It's faster than svn/svk(I've used both with
> ofbiz).  For another project, it beats mercurial as well(except when
> throwing a 40G repo at it, but only in certain cases).
>
> History rewriting is wonderful.  Local branching is heavenly.  Local
> copy of the entire ofbiz history is extremely cool.
>
> There are plenty of existing docs out there that talk about how to use
> a central svn repo, but git locally.  You can git svn clone to your
> laptop, walk around, grab a coffe, sit in a hotel lobby, commit lots
> of changes, then reconnect back in your room at night and send all
> your separate, *individual* changes.

My guess is this is how things will go with the ASF source repos for a  
while, ie SVN remaining the "master" for most projects. Using git  
locally, or for smaller workgroups, sounds like it is a great way to  
go and will add a lot of flexibility that an SVN client can't give you.

-David


> Some may even remember last year at ApacheCon where I was using
> mercurial+ofbiz/svn.

[Raul Sieberath]

Jacques,

1 - Everyone has the whole history of development, what also is good
for backup.
2 - It is distributed.
  This means there is no central repository. No central
  repository means that we do not need commiters as we need with SVN.
  However, the community still have the people they trust. For example,
  I fix something and I tell people that I fixed and it is available in
  my branch (branch is fast. I mean really fast). Now, how this fix get
  to the community. I will need to do the same as I do today. I will
  tell someone that has the respect of the community to merge my fix
  into his branch. In this case, I could tell you to test my fix. You
  would decide when to do it, and when you have time you go ahead and
  merge my fix into your development branch (remember branch is fast),
  and if you like my fix, then you merge into your stable branch. You
  push your branch to a server point where people can pull from. The
  community gets my fix because they trust you and you have my fix in
  your stable branch.
  I think the main difference is that we do not work with diff anymore.
  Each developer has a branch, and people get the patch directly in
  the repository.
  The file format is also very efficient and small. Even if everyone in
  this list had one or more branches the system keep the tree very
  small.

About bigger commits, it is actually the contrary. You commit several
times in your local machine. Then you push. When I pull after your
push, I get all history commits you have done. Not one big change. I
actually get everything.

Well, I tried to explain from a perspective of someone that use svn.
In the same way it is done today. People can try the fix pull from my
branch and comment in the list that my fix is good or not.

I hope it helped instead of confusing people more. But there are other
people here using git and they can point out any mistakes I made or
other scenarios.

Raul

On Thu, 22 Oct 2009 19:01:23 +0200
"Jacques Le Roux" <[hidden email]> wrote:

> Thanks for comment Raul,
>
> How does it change the workflow, what does it changes ? Could you
> elaborate a bit more please ? I have read on Apache MLs that some
> persons are against using Git because, they say, it's not good for
> collaboration. Their arguments is to say that, contrary as Subversion
> general usage, with Git the tendency is to have bigger commit because
> people work more isolated and then commit whole blocks of changes
>
> Jacques
>
> From: "Raul Sieberath" <[hidden email]>
> > GIT is really a very good tool. I use it locally and for other
> > projects. However, it does change the work flow of development.
> >
> > My 2 cents
> >
> > Raul
> >
> > On Thu, 22 Oct 2009 01:14:57 -0500
> > Ean Schuessler <[hidden email]> wrote:
> >
> >> Adrian Crum wrote:
> >> > I share some of the frustration Tim expressed, but at the same
> >> > time I really appreciate the valuable contributions your company
> >> > has made to the project.
> >> >
> >> > All I would ask is that you spend a little more time reviewing
> >> > code and testing it before committing it.
> >> Which brings up back to the value of the GIT-based pull-oriented
> >> workflow. In the Linux kernel when someone has a feature they say
> >> "people come checkout my repo for the cool thing I did" and people
> >> go examine the work. The code doesn't go into someone's tree until
> >> they already approve of it. If they have a complain they might say
> >> "fix X, Y and Z and I will merge in your code".
> >>
> >> This way, if someone finds a "sloppier" workflow productive... so
> >> be it. It may not get merged until they fix it up or someone works
> >> with them to fix it up and it finally meets approval. The value
> >> is, people who are not bothered by the sloppy workflow might work
> >> fast and loose to prototype up some new feature.
> >
>
>

[Tim Ruppert]

Thanks Raul - I have to admit that I like it and am happy to give it a  
+1 from over here.

Cheers,
Ruppert

On Oct 22, 2009, at 4:05 PM, Raul Sieberath wrote:

> Jacques,
>
> 1 - Everyone has the whole history of development, what also is good
> for backup.
> 2 - It is distributed.
>  This means there is no central repository. No central
>  repository means that we do not need commiters as we need with SVN.
>  However, the community still have the people they trust. For example,
>  I fix something and I tell people that I fixed and it is available in
>  my branch (branch is fast. I mean really fast). Now, how this fix get
>  to the community. I will need to do the same as I do today. I will
>  tell someone that has the respect of the community to merge my fix
>  into his branch. In this case, I could tell you to test my fix. You
>  would decide when to do it, and when you have time you go ahead and
>  merge my fix into your development branch (remember branch is fast),
>  and if you like my fix, then you merge into your stable branch. You
>  push your branch to a server point where people can pull from. The
>  community gets my fix because they trust you and you have my fix in
>  your stable branch.
>  I think the main difference is that we do not work with diff anymore.
>  Each developer has a branch, and people get the patch directly in
>  the repository.
>  The file format is also very efficient and small. Even if everyone in
>  this list had one or more branches the system keep the tree very
>  small.
>
> About bigger commits, it is actually the contrary. You commit several
> times in your local machine. Then you push. When I pull after your
> push, I get all history commits you have done. Not one big change. I
> actually get everything.
>
> Well, I tried to explain from a perspective of someone that use svn.
> In the same way it is done today. People can try the fix pull from my
> branch and comment in the list that my fix is good or not.
>
> I hope it helped instead of confusing people more. But there are other
> people here using git and they can point out any mistakes I made or
> other scenarios.
>
> Raul
>
> On Thu, 22 Oct 2009 19:01:23 +0200
> "Jacques Le Roux" <[hidden email]> wrote:
>
>> Thanks for comment Raul,
>>
>> How does it change the workflow, what does it changes ? Could you
>> elaborate a bit more please ? I have read on Apache MLs that some
>> persons are against using Git because, they say, it's not good for
>> collaboration. Their arguments is to say that, contrary as Subversion
>> general usage, with Git the tendency is to have bigger commit because
>> people work more isolated and then commit whole blocks of changes
>>
>> Jacques
>>
>> From: "Raul Sieberath" <[hidden email]>
>>> GIT is really a very good tool. I use it locally and for other
>>> projects. However, it does change the work flow of development.
>>>
>>> My 2 cents
>>>
>>> Raul
>>>
>>> On Thu, 22 Oct 2009 01:14:57 -0500
>>> Ean Schuessler <[hidden email]> wrote:
>>>
>>>> Adrian Crum wrote:
>>>>> I share some of the frustration Tim expressed, but at the same
>>>>> time I really appreciate the valuable contributions your company
>>>>> has made to the project.
>>>>>
>>>>> All I would ask is that you spend a little more time reviewing
>>>>> code and testing it before committing it.
>>>> Which brings up back to the value of the GIT-based pull-oriented
>>>> workflow. In the Linux kernel when someone has a feature they say
>>>> "people come checkout my repo for the cool thing I did" and people
>>>> go examine the work. The code doesn't go into someone's tree until
>>>> they already approve of it. If they have a complain they might say
>>>> "fix X, Y and Z and I will merge in your code".
>>>>
>>>> This way, if someone finds a "sloppier" workflow productive... so
>>>> be it. It may not get merged until they fix it up or someone works
>>>> with them to fix it up and it finally meets approval. The value
>>>> is, people who are not bothered by the sloppy workflow might work
>>>> fast and loose to prototype up some new feature.
>>>
>>
>>
>

[Adam Heath-2]

Tim Ruppert wrote:
> Just so everyone is on the up and up, Hans and I are offline reconciling
> _both_ "attacks" and will figure a way forward.  Thanks for the help and
> the concern.

Offline?  Why?  This incident occurred in public, so should be
resolved in public.  Private emails, private phone calls, are very
much bad form.

Additionally, if there are internal things(thoughts, circumstances,
etc) that make you(or anyone else) think a certain way, then it's not
correct for you to get upset when the rest of us call you(or whoever)
out about it.  We do *not* know what makes other people tick.  We can
only see what is *done*.

[Ryan Foster]

I really was trying not to say anything here, first because I do not  
wish to add any fuel to the fire, and secondly because this  
conversation did not personally concern me.  However, I fail see any  
circumstance when a personal conversation is "very much bad form".  
Isn't the opposite generally true?  I have found that if two people  
are having a disagreement, a phone call clears the air much, much  
faster than a vague, insincere, public mailing list.  Wouldn't you  
agree?

Just because something starts in public, doesn't mean it has to end in  
public.  If I lose my temper and yell at my wife in the middle of the  
grocery store, I am certainly not going to take her back there  
tomorrow and apologize to her in front of the cashier and the stock  
boy.  It's none of their business, and it's none of yours either.  As  
far as I am concerned, this conversation was a disagreement between  
Hans and Tim.  If they decide they want to resolve their conflicts by  
emailing each other privately, Tim calls to apologize to Hans, Hans  
calls to apologize to Tim, or the two of them sit down and have a beer  
together at ApacheCon and then punch each other in the face, that is  
really none of my business.

Let's keep the dev list for discussions about OFBiz development.

Ryan Foster
HotWax Media
801.671.0769
[hidden email]




On Oct 22, 2009, at 4:20 PM, Adam Heath wrote:

> Tim Ruppert wrote:
>> Just so everyone is on the up and up, Hans and I are offline  
>> reconciling
>> _both_ "attacks" and will figure a way forward.  Thanks for the  
>> help and
>> the concern.
>
> Offline?  Why?  This incident occurred in public, so should be
> resolved in public.  Private emails, private phone calls, are very
> much bad form.
>
> Additionally, if there are internal things(thoughts, circumstances,
> etc) that make you(or anyone else) think a certain way, then it's not
> correct for you to get upset when the rest of us call you(or whoever)
> out about it.  We do *not* know what makes other people tick.  We can
> only see what is *done*.
>

[Jacques Le Roux]

Thanks Raul,

It helped me to understand the process, and yes this seems like an interesting process indeed

Jacques

From: "Raul Sieberath" <[hidden email]>

> Jacques,
>
> 1 - Everyone has the whole history of development, what also is good
> for backup.
> 2 - It is distributed.
>  This means there is no central repository. No central
>  repository means that we do not need commiters as we need with SVN.
>  However, the community still have the people they trust. For example,
>  I fix something and I tell people that I fixed and it is available in
>  my branch (branch is fast. I mean really fast). Now, how this fix get
>  to the community. I will need to do the same as I do today. I will
>  tell someone that has the respect of the community to merge my fix
>  into his branch. In this case, I could tell you to test my fix. You
>  would decide when to do it, and when you have time you go ahead and
>  merge my fix into your development branch (remember branch is fast),
>  and if you like my fix, then you merge into your stable branch. You
>  push your branch to a server point where people can pull from. The
>  community gets my fix because they trust you and you have my fix in
>  your stable branch.
>  I think the main difference is that we do not work with diff anymore.
>  Each developer has a branch, and people get the patch directly in
>  the repository.
>  The file format is also very efficient and small. Even if everyone in
>  this list had one or more branches the system keep the tree very
>  small.
>
> About bigger commits, it is actually the contrary. You commit several
> times in your local machine. Then you push. When I pull after your
> push, I get all history commits you have done. Not one big change. I
> actually get everything.
>
> Well, I tried to explain from a perspective of someone that use svn.
> In the same way it is done today. People can try the fix pull from my
> branch and comment in the list that my fix is good or not.
>
> I hope it helped instead of confusing people more. But there are other
> people here using git and they can point out any mistakes I made or
> other scenarios.
>
> Raul
>
> On Thu, 22 Oct 2009 19:01:23 +0200
> "Jacques Le Roux" <[hidden email]> wrote:
>
>> Thanks for comment Raul,
>>
>> How does it change the workflow, what does it changes ? Could you
>> elaborate a bit more please ? I have read on Apache MLs that some
>> persons are against using Git because, they say, it's not good for
>> collaboration. Their arguments is to say that, contrary as Subversion
>> general usage, with Git the tendency is to have bigger commit because
>> people work more isolated and then commit whole blocks of changes
>>
>> Jacques
>>
>> From: "Raul Sieberath" <[hidden email]>
>> > GIT is really a very good tool. I use it locally and for other
>> > projects. However, it does change the work flow of development.
>> >
>> > My 2 cents
>> >
>> > Raul
>> >
>> > On Thu, 22 Oct 2009 01:14:57 -0500
>> > Ean Schuessler <[hidden email]> wrote:
>> >
>> >> Adrian Crum wrote:
>> >> > I share some of the frustration Tim expressed, but at the same
>> >> > time I really appreciate the valuable contributions your company
>> >> > has made to the project.
>> >> >
>> >> > All I would ask is that you spend a little more time reviewing
>> >> > code and testing it before committing it.
>> >> Which brings up back to the value of the GIT-based pull-oriented
>> >> workflow. In the Linux kernel when someone has a feature they say
>> >> "people come checkout my repo for the cool thing I did" and people
>> >> go examine the work. The code doesn't go into someone's tree until
>> >> they already approve of it. If they have a complain they might say
>> >> "fix X, Y and Z and I will merge in your code".
>> >>
>> >> This way, if someone finds a "sloppier" workflow productive... so
>> >> be it. It may not get merged until they fix it up or someone works
>> >> with them to fix it up and it finally meets approval. The value
>> >> is, people who are not bothered by the sloppy workflow might work
>> >> fast and loose to prototype up some new feature.
>> >
>>
>>
>

[Pierre Smits]

Hi Raul,
So if I understand your posting correctly you use a git-server in your own
development environment and perhaps a plugin in eclipse?

Regards,

Pierre

2009/10/23 Raul Sieberath <[hidden email]>

> Jacques,
>
> 1 - Everyone has the whole history of development, what also is good
> for backup.
> 2 - It is distributed.
>  This means there is no central repository. No central
>  repository means that we do not need commiters as we need with SVN.
>  However, the community still have the people they trust. For example,
>  I fix something and I tell people that I fixed and it is available in
>  my branch (branch is fast. I mean really fast). Now, how this fix get
>  to the community. I will need to do the same as I do today. I will
>  tell someone that has the respect of the community to merge my fix
>  into his branch. In this case, I could tell you to test my fix. You
>  would decide when to do it, and when you have time you go ahead and
>  merge my fix into your development branch (remember branch is fast),
>  and if you like my fix, then you merge into your stable branch. You
>  push your branch to a server point where people can pull from. The
>  community gets my fix because they trust you and you have my fix in
>  your stable branch.
>  I think the main difference is that we do not work with diff anymore.
>  Each developer has a branch, and people get the patch directly in
>  the repository.
>  The file format is also very efficient and small. Even if everyone in
>  this list had one or more branches the system keep the tree very
>  small.
>
> About bigger commits, it is actually the contrary. You commit several
> times in your local machine. Then you push. When I pull after your
> push, I get all history commits you have done. Not one big change. I
> actually get everything.
>
> Well, I tried to explain from a perspective of someone that use svn.
> In the same way it is done today. People can try the fix pull from my
> branch and comment in the list that my fix is good or not.
>
> I hope it helped instead of confusing people more. But there are other
> people here using git and they can point out any mistakes I made or
> other scenarios.
>
> Raul
>
> On Thu, 22 Oct 2009 19:01:23 +0200
> "Jacques Le Roux" <[hidden email]> wrote:
>
> > Thanks for comment Raul,
> >
> > How does it change the workflow, what does it changes ? Could you
> > elaborate a bit more please ? I have read on Apache MLs that some
> > persons are against using Git because, they say, it's not good for
> > collaboration. Their arguments is to say that, contrary as Subversion
> > general usage, with Git the tendency is to have bigger commit because
> > people work more isolated and then commit whole blocks of changes
> >
> > Jacques
> >
> > From: "Raul Sieberath" <[hidden email]>
> > > GIT is really a very good tool. I use it locally and for other
> > > projects. However, it does change the work flow of development.
> > >
> > > My 2 cents
> > >
> > > Raul
> > >
> > > On Thu, 22 Oct 2009 01:14:57 -0500
> > > Ean Schuessler <[hidden email]> wrote:
> > >
> > >> Adrian Crum wrote:
> > >> > I share some of the frustration Tim expressed, but at the same
> > >> > time I really appreciate the valuable contributions your company
> > >> > has made to the project.
> > >> >
> > >> > All I would ask is that you spend a little more time reviewing
> > >> > code and testing it before committing it.
> > >> Which brings up back to the value of the GIT-based pull-oriented
> > >> workflow. In the Linux kernel when someone has a feature they say
> > >> "people come checkout my repo for the cool thing I did" and people
> > >> go examine the work. The code doesn't go into someone's tree until
> > >> they already approve of it. If they have a complain they might say
> > >> "fix X, Y and Z and I will merge in your code".
> > >>
> > >> This way, if someone finds a "sloppier" workflow productive... so
> > >> be it. It may not get merged until they fix it up or someone works
> > >> with them to fix it up and it finally meets approval. The value
> > >> is, people who are not bothered by the sloppy workflow might work
> > >> fast and loose to prototype up some new feature.
> > >
> >
> >
>
>

[Raul Sieberath]

Pierre,

actually git does not have a server installation. It does not have
server daemon, and it is not necessary.

Git in a collection of programs and scripts. They implemented in c what
need to me fast and the rest is perl or python. I do not remember right
now.

Anyway, to understand the reason that a server software is not
necessary, I need to explain a bit about the file format used to keep
the data.

Every piece of information has a SHA signature, and this signature
depends on everything is under it. So, if you clone a git branch and
you want to push it back (it is actually just a folder share). Git will
compare your top most sha signature with the top most signature on the
share. They will be the same and it decides thera are no deltas to be
transmitted. But than you go ahead and change one character in the
deepest folder, commit (this will recalculate the sha of from top to
bottom) when you push, git will compared the top most sha signature and
find it is different. Then it has the full history, so it calculates
the delta locally and push it to the copy in the share.

The file structure is very clever, I think any programmer should read
it for the fun of it.

So, there are Git plug-ins for eclipse. They can use the git
executables and scripts or it can implement in java.

Any question let me know.

Raul


On Fri, 23 Oct 2009 10:07:16 +0200
Pierre Smits <[hidden email]> wrote:

> Hi Raul,
> So if I understand your posting correctly you use a git-server in
> your own development environment and perhaps a plugin in eclipse?
>
> Regards,
>
> Pierre
>
> 2009/10/23 Raul Sieberath <[hidden email]>
>
> > Jacques,
> >
> > 1 - Everyone has the whole history of development, what also is good
> > for backup.
> > 2 - It is distributed.
> >  This means there is no central repository. No central
> >  repository means that we do not need commiters as we need with SVN.
> >  However, the community still have the people they trust. For
> > example, I fix something and I tell people that I fixed and it is
> > available in my branch (branch is fast. I mean really fast). Now,
> > how this fix get to the community. I will need to do the same as I
> > do today. I will tell someone that has the respect of the community
> > to merge my fix into his branch. In this case, I could tell you to
> > test my fix. You would decide when to do it, and when you have time
> > you go ahead and merge my fix into your development branch
> > (remember branch is fast), and if you like my fix, then you merge
> > into your stable branch. You push your branch to a server point
> > where people can pull from. The community gets my fix because they
> > trust you and you have my fix in your stable branch.
> >  I think the main difference is that we do not work with diff
> > anymore. Each developer has a branch, and people get the patch
> > directly in the repository.
> >  The file format is also very efficient and small. Even if everyone
> > in this list had one or more branches the system keep the tree very
> >  small.
> >
> > About bigger commits, it is actually the contrary. You commit
> > several times in your local machine. Then you push. When I pull
> > after your push, I get all history commits you have done. Not one
> > big change. I actually get everything.
> >
> > Well, I tried to explain from a perspective of someone that use svn.
> > In the same way it is done today. People can try the fix pull from
> > my branch and comment in the list that my fix is good or not.
> >
> > I hope it helped instead of confusing people more. But there are
> > other people here using git and they can point out any mistakes I
> > made or other scenarios.
> >
> > Raul
> >
> > On Thu, 22 Oct 2009 19:01:23 +0200
> > "Jacques Le Roux" <[hidden email]> wrote:
> >
> > > Thanks for comment Raul,
> > >
> > > How does it change the workflow, what does it changes ? Could you
> > > elaborate a bit more please ? I have read on Apache MLs that some
> > > persons are against using Git because, they say, it's not good for
> > > collaboration. Their arguments is to say that, contrary as
> > > Subversion general usage, with Git the tendency is to have bigger
> > > commit because people work more isolated and then commit whole
> > > blocks of changes
> > >
> > > Jacques
> > >
> > > From: "Raul Sieberath" <[hidden email]>
> > > > GIT is really a very good tool. I use it locally and for other
> > > > projects. However, it does change the work flow of development.
> > > >
> > > > My 2 cents
> > > >
> > > > Raul
> > > >
> > > > On Thu, 22 Oct 2009 01:14:57 -0500
> > > > Ean Schuessler <[hidden email]> wrote:
> > > >
> > > >> Adrian Crum wrote:
> > > >> > I share some of the frustration Tim expressed, but at the
> > > >> > same time I really appreciate the valuable contributions
> > > >> > your company has made to the project.
> > > >> >
> > > >> > All I would ask is that you spend a little more time
> > > >> > reviewing code and testing it before committing it.
> > > >> Which brings up back to the value of the GIT-based
> > > >> pull-oriented workflow. In the Linux kernel when someone has a
> > > >> feature they say "people come checkout my repo for the cool
> > > >> thing I did" and people go examine the work. The code doesn't
> > > >> go into someone's tree until they already approve of it. If
> > > >> they have a complain they might say "fix X, Y and Z and I will
> > > >> merge in your code".
> > > >>
> > > >> This way, if someone finds a "sloppier" workflow productive...
> > > >> so be it. It may not get merged until they fix it up or
> > > >> someone works with them to fix it up and it finally meets
> > > >> approval. The value is, people who are not bothered by the
> > > >> sloppy workflow might work fast and loose to prototype up some
> > > >> new feature.
> > > >
> > >
> > >
> >
> >

[Ean Schuessler]

Raul Sieberath wrote:
> So, there are Git plug-ins for eclipse. They can use the git
> executables and scripts or it can implement in java.
>  
Which is very interesting, actually. JGit is an implementation of GIT in
Java under the BSD license. I've been interested for some time in
turning this into the backing store for the content management system.
Most content management tools have a simplistic history oriented
approach that just doesn't match up with the way the world works. It is
common to have a site in production with high priority changes going in
all the time while, at the same time, you have a set of new content
being developed on another server. Merging those change sets with a
database oriented content management system basically sucks. If a friend
GUI could be put on top of the GIT star topology revision control it
would be a category defining feature for content management.

I've been very curious whether this could be done in Jackrabbit so that
you have JCR compliance in one fell swoop.

[Tim Ruppert]

That is a fantastic idea - I guess it'd be super easy to scale the  
datastore then right?

Cheers,
Ruppert

On Oct 24, 2009, at 1:35 PM, Ean Schuessler wrote:

> Raul Sieberath wrote:
>> So, there are Git plug-ins for eclipse. They can use the git
>> executables and scripts or it can implement in java.
>>
> Which is very interesting, actually. JGit is an implementation of  
> GIT in Java under the BSD license. I've been interested for some  
> time in turning this into the backing store for the content  
> management system. Most content management tools have a simplistic  
> history oriented approach that just doesn't match up with the way  
> the world works. It is common to have a site in production with high  
> priority changes going in all the time while, at the same time, you  
> have a set of new content being developed on another server. Merging  
> those change sets with a database oriented content management system  
> basically sucks. If a friend GUI could be put on top of the GIT star  
> topology revision control it would be a category defining feature  
> for content management.
>
> I've been very curious whether this could be done in Jackrabbit so  
> that you have JCR compliance in one fell swoop.

[Jacques Le Roux]

Is JGit reliable (BTW I work mostly on Windows...) ?

Thanks

Jacques

From: "Ean Schuessler" <[hidden email]>

> Raul Sieberath wrote:
>> So, there are Git plug-ins for eclipse. They can use the git
>> executables and scripts or it can implement in java.
>>  
> Which is very interesting, actually. JGit is an implementation of GIT in
> Java under the BSD license. I've been interested for some time in
> turning this into the backing store for the content management system.
> Most content management tools have a simplistic history oriented
> approach that just doesn't match up with the way the world works. It is
> common to have a site in production with high priority changes going in
> all the time while, at the same time, you have a set of new content
> being developed on another server. Merging those change sets with a
> database oriented content management system basically sucks. If a friend
> GUI could be put on top of the GIT star topology revision control it
> would be a category defining feature for content management.
>
> I've been very curious whether this could be done in Jackrabbit so that
> you have JCR compliance in one fell swoop.
>

[Jacques Le Roux]

I will also try TortoiseGIt and integration in MS File explorer

Jacques

From: "Jacques Le Roux" <[hidden email]>

> Is JGit reliable (BTW I work mostly on Windows...) ?
>
> Thanks
>
> Jacques
>
> From: "Ean Schuessler" <[hidden email]>
>> Raul Sieberath wrote:
>>> So, there are Git plug-ins for eclipse. They can use the git
>>> executables and scripts or it can implement in java.
>>>  
>> Which is very interesting, actually. JGit is an implementation of GIT in
>> Java under the BSD license. I've been interested for some time in
>> turning this into the backing store for the content management system.
>> Most content management tools have a simplistic history oriented
>> approach that just doesn't match up with the way the world works. It is
>> common to have a site in production with high priority changes going in
>> all the time while, at the same time, you have a set of new content
>> being developed on another server. Merging those change sets with a
>> database oriented content management system basically sucks. If a friend
>> GUI could be put on top of the GIT star topology revision control it
>> would be a category defining feature for content management.
>>
>> I've been very curious whether this could be done in Jackrabbit so that
>> you have JCR compliance in one fell swoop.
>>
>

[Ean Schuessler]

Jacques Le Roux wrote:
> Is JGit reliable (BTW I work mostly on Windows...) ?
Its apparently reliable enough to serve as the basis for Eclipse GIT
support. I haven't used it in production.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com