You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Daniel Spiewak <dj...@gmail.com> on 2009/03/01 05:52:32 UTC
Welcome to Rebase Hell!
Those of you following development progress using Git are probably starting
to notice that the classical "Vic Master" is no longer the all-knowing
source of data. Actually, Assaf's GitHub fork has become the more
trustworthy one. This is because upon its exit from incubation, Buildr gets
to move its SVN repository to a new URL. This is good for the project, but
bad for the Git forks since git-svn stores the URL information in its commit
messages.
The solution of course is to re-clone from SVN, which I assume exactly what
Assaf did. There result is a repository which contains all of the same SVN
commits as Vic's, but different messages and very different SHA1 revisions,
meaning that Git has a much harder time merging between the two. I
discovered this when I attempted to merge Assaf's latest changes with my
master (forked from Vic's). 57 conflicts later (all petty, little issues
unrelated to my additions), I finally had a working master with the latest
commits. Unfortunately, when I cloned Assaf's repository directly and
attempted to merge back some of my changes, it became very apparent that I
would need to fix the issue in a more scientific manner.
Long story short, the solution is to rebase all of your branches onto
Assaf's master. I did this by finding the exact commit where I diverged
from vic (I had it tagged, actually) as well as the corresponding commit in
Assaf's master. These commits I tagged "branch-point" and
"new-branch-point", respectively. Then for each branch, I did something
like the following:
git checkout scala-joint-compilation
git rebase new-branch-point
Once this was done, I went back to my master and performed a similar
procedure:
git checkout master
git rebase -s ours new-branch-point
This effectively wiped out all of my changes in that branch (it's possible
that some commits may remain if you try it, but none did in my case). Once
this was done, I went and picked through my origin/master log to see what I
was missing. This meant re-merging all of my branches:
git merge scala-joint-compilation
git merge clojure
...
Also, I had to cherry-pick a few commits that I had done on master (like
four or five):
git cherry-pick all-your-ant-base
...
Once this was done, I pushed the result back to GitHub:
git push -f origin
The one caveat to this approach is I had all of my changes on numerous
separate branches (for patching reasons). All of these branches were
branched off of the same point on vic/master. Since there hadn't been any
merging *between* the branches (only onto master), it was fairly easy to
just rebase these branches onto the new trunk (I only had three conflicts in
the whole process, all easily resolved). Just judging by GitHub, not many
people are managing their repositories in this fashion. However, this does
mean that you could be able to just rebase without the "-s ours" on your
master and come to the same result.
The point is that you will need to perform some conniptions of this sort in
order to fix your repositories, otherwise your changes will remain
incompatible with the Buildr mainline trunk: you won't be able to (easily)
merge assaf/master, and he won't be able to (easily) pull from you.
Incidentally, if anyone has a *better* way of doing this (particularly one
where the entire master history doesn't get wiped out), I'm all ears! I do
still have the unmerged repository sitting in Time Machine, so I'm perfectly
willing to roll-forward a copy and try again if the result turns out to be
more correct.
Daniel
Re: Welcome to Rebase Hell!
Posted by Daniel Spiewak <dj...@gmail.com>.
I like the idea of building a new GitHub clone based on the SVN.
Rebasing all the experimental stuff is tedious (especially for non-
commiters), but there really is no way around it.
Daniel
On Mar 1, 2009, at 6:57 AM, Victor Hugo Borja <vi...@gmail.com>
wrote:
> I guess Buildr was one of the first Apache projects using git for
> development. Our github mirror at vic/buildr from incubation days was
> created from svn.apache.org server, and as Assaf mentions, TLP there
> seems
> to be some restrictions on using git-svn on asf/ directory level on
> that
> server, so our best bet would be to use eu.svn..
>
> One issue is duplication of commits history because Git uses the
> author
> name/email to create the hash for a commit. Actually we faced this
> problem
> back early when we started playing with git, a bare git-svn clone from
> svn.apache.org would have git-svn generated user name/email for the
> commit
> hash. When we pushed into github, we did using our real name and the
> email
> address we were using for our github account. That caused our commit
> history
> duplication due to having different user info on each commit, we
> kinda
> solved it using a etc/git-svn-authors file so that git-svn could
> know which
> apache account mapped to github accounts.
>
> Now, we could easily use Jukka's git mirror[1] but we have some
> issues to
> solve.. Jukka's mirror was created by a bare git-svn checkout (yet
> it uses
> our real user names and apache addrs), so if we push these commits
> to github
> we would have again a duplication of commit history, because commits
> on
> Jukka's mirror have been signed with our apache account and know
> nothing
> about github (doesn't use etc/git-svn-authors).
>
> I'd propose using [1] and push a fresh clone from it to vic/buildr.
> Using
> GitHub IMHO has many advantages over just using [1], first is we
> have more
> control over when to update the mirror with current branch, and can
> keep it
> more up-to-date if needed, we can push directly to it, and easily
> use the
> fork queue to integrate other's changes. In doing this we (buildr
> commiters
> using github) would need to make some changes..
>
> - Get a fresh clone from [1] and cd into it
> - Use your apache account to git push (would have done this from the
> beginning)
> git config user.email you@apache.org
> add you@apache.org on your github account so it can recognize
> changes
> made by you.
> - Now the tedious thing would be to get changes from your
> experimental
> branches into your new clone without having duplicate commits.
> - I would update git-svn-authors to use our apache email addresses,
> and
> also update the buildr-git to use eu.svn as [1] does.
>
> What you think about this?
>
> [1] http://jukka.zitting.name/git/?p=buildr.git;a=summary
> --
> vic
>
> Quaerendo invenietis.
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Mar 2, 2009, at 1:47 AM, Martijn Dashorst
<ma...@gmail.com> wrote:
> I've read it, and have problems understanding what you mean by main
> repository then?
>
> Nowhere in Vic's message do I see a synchronization step where commits
> end up in svn?
>
Vic created a wonderful script that synchs both ways. It's in SVN (or
Git for that matter) if you're interested in checking it out. We've
been using it for months while in incubator.
The discussion today is whether the main Git repository we direct
people to should be Jukka's or Github (most likely vic/buildr).
Assaf
> Martijn
>
> On Mon, Mar 2, 2009 at 10:17 AM, Assaf Arkin <ar...@intalio.com>
> wrote:
>> On Mon, Mar 2, 2009 at 1:07 AM, Martijn Dashorst <martijn.dashorst@gmail.com
>>> wrote:
>>
>>> On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com>
>>> wrote:
>>>> I'm with you in using Github as the main repository:
>>>
>>> As an ASF Member I must protest against the direction that you are
>>> taking this project. GitHub can not be used as the main repository
>>> for
>>> any ASF Project. The canonical resource for Apache project's code
>>> must
>>> be hosted on Apache hardware. Since the only repository that is
>>> supported by Infrastructure is SVN, you'll have to maintain the
>>> primary source for your project *in* SVN. Not somewhere else, not
>>> bypassing ASF authorizations, not bypassing Apache policy.
>>>
>>
>> Since when have we not made Buildr code available through SVN?
>>
>> You're reading my comment sans context. You have to start with
>> Vic's email
>> to which I'm replying.
>>
>> Assaf
>>
>>
>>>
>>> Martijn
>>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Mar 2, 2009 at 1:52 AM, Martijn Dashorst <martijn.dashorst@gmail.com
> wrote:
> Please note, that I am fan of github. I'd wish Apache would have the
> same infrastructure as github. It would give the ASF Community a real
> sparkle: the social aspects of github are really nice.
I think Apache should stay out of the infrastructure business altogether.
They should provide only the bare minimum that is necessary to follow the
Apache Way. They do it with email, they give you an address but no email
client; mailing lists are hosted by Apache, but many people use far better
archives to access them (nibble, markmail, etc); projects can run their own
build or CI servers, etc. Same with source control: they should host the
licensed and reviewed contributions repositories, and let people figure out
the UI on their own. Then we could use a hosted service like Github, which
is not something Apache can provide, and the infrastructure pain for Apache
will drop, since very few people will be hammering their Git repo (mostly
committers and CI).
Assaf
>
>
> Martijn
>
> On Mon, Mar 2, 2009 at 10:47 AM, Martijn Dashorst
> <ma...@gmail.com> wrote:
> > I've read it, and have problems understanding what you mean by main
> > repository then?
> >
> > Nowhere in Vic's message do I see a synchronization step where commits
> > end up in svn?
> >
> > Martijn
> >
> > On Mon, Mar 2, 2009 at 10:17 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >> On Mon, Mar 2, 2009 at 1:07 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com
> >>> wrote:
> >>
> >>> On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >>> > I'm with you in using Github as the main repository:
> >>>
> >>> As an ASF Member I must protest against the direction that you are
> >>> taking this project. GitHub can not be used as the main repository for
> >>> any ASF Project. The canonical resource for Apache project's code must
> >>> be hosted on Apache hardware. Since the only repository that is
> >>> supported by Infrastructure is SVN, you'll have to maintain the
> >>> primary source for your project *in* SVN. Not somewhere else, not
> >>> bypassing ASF authorizations, not bypassing Apache policy.
> >>>
> >>
> >> Since when have we not made Buildr code available through SVN?
> >>
> >> You're reading my comment sans context. You have to start with Vic's
> email
> >> to which I'm replying.
> >>
> >> Assaf
> >>
> >>
> >>>
> >>> Martijn
> >>>
> >>
> >
> >
> >
> > --
> > Become a Wicket expert, learn from the best: http://wicketinaction.com
> > Apache Wicket 1.3.5 is released
> > Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
> >
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
Re: Welcome to Rebase Hell!
Posted by Martijn Dashorst <ma...@gmail.com>.
Please note, that I am fan of github. I'd wish Apache would have the
same infrastructure as github. It would give the ASF Community a real
sparkle: the social aspects of github are really nice.
Martijn
On Mon, Mar 2, 2009 at 10:47 AM, Martijn Dashorst
<ma...@gmail.com> wrote:
> I've read it, and have problems understanding what you mean by main
> repository then?
>
> Nowhere in Vic's message do I see a synchronization step where commits
> end up in svn?
>
> Martijn
>
> On Mon, Mar 2, 2009 at 10:17 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> On Mon, Mar 2, 2009 at 1:07 AM, Martijn Dashorst <martijn.dashorst@gmail.com
>>> wrote:
>>
>>> On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
>>> > I'm with you in using Github as the main repository:
>>>
>>> As an ASF Member I must protest against the direction that you are
>>> taking this project. GitHub can not be used as the main repository for
>>> any ASF Project. The canonical resource for Apache project's code must
>>> be hosted on Apache hardware. Since the only repository that is
>>> supported by Infrastructure is SVN, you'll have to maintain the
>>> primary source for your project *in* SVN. Not somewhere else, not
>>> bypassing ASF authorizations, not bypassing Apache policy.
>>>
>>
>> Since when have we not made Buildr code available through SVN?
>>
>> You're reading my comment sans context. You have to start with Vic's email
>> to which I'm replying.
>>
>> Assaf
>>
>>
>>>
>>> Martijn
>>>
>>
>
>
>
> --
> Become a Wicket expert, learn from the best: http://wicketinaction.com
> Apache Wicket 1.3.5 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: Welcome to Rebase Hell!
Posted by Martijn Dashorst <ma...@gmail.com>.
I've read it, and have problems understanding what you mean by main
repository then?
Nowhere in Vic's message do I see a synchronization step where commits
end up in svn?
Martijn
On Mon, Mar 2, 2009 at 10:17 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On Mon, Mar 2, 2009 at 1:07 AM, Martijn Dashorst <martijn.dashorst@gmail.com
>> wrote:
>
>> On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
>> > I'm with you in using Github as the main repository:
>>
>> As an ASF Member I must protest against the direction that you are
>> taking this project. GitHub can not be used as the main repository for
>> any ASF Project. The canonical resource for Apache project's code must
>> be hosted on Apache hardware. Since the only repository that is
>> supported by Infrastructure is SVN, you'll have to maintain the
>> primary source for your project *in* SVN. Not somewhere else, not
>> bypassing ASF authorizations, not bypassing Apache policy.
>>
>
> Since when have we not made Buildr code available through SVN?
>
> You're reading my comment sans context. You have to start with Vic's email
> to which I'm replying.
>
> Assaf
>
>
>>
>> Martijn
>>
>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.5 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Mar 2, 2009 at 1:07 AM, Martijn Dashorst <martijn.dashorst@gmail.com
> wrote:
> On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
> > I'm with you in using Github as the main repository:
>
> As an ASF Member I must protest against the direction that you are
> taking this project. GitHub can not be used as the main repository for
> any ASF Project. The canonical resource for Apache project's code must
> be hosted on Apache hardware. Since the only repository that is
> supported by Infrastructure is SVN, you'll have to maintain the
> primary source for your project *in* SVN. Not somewhere else, not
> bypassing ASF authorizations, not bypassing Apache policy.
>
Since when have we not made Buildr code available through SVN?
You're reading my comment sans context. You have to start with Vic's email
to which I'm replying.
Assaf
>
> Martijn
>
Re: Welcome to Rebase Hell!
Posted by Daniel Spiewak <dj...@gmail.com>.
I like the term "town-hall repository" to serve as a central, trustworthy
point for forking (in the good way) and contribution back into the project
with less red tape than a central repo. To be clear, this town-hall repo
should always remain synced with the main repository, being a less
authoritative source than the official upstream. However, because this repo
is more accessible to the community and more interactive (faster turnaround
for patches, lower bar for entry, etc) potential contributions are
encouraged to a far higher degree. People (like myself) who would never
have taken the time to contribute patches in a purely-authoritative
environment are now given exactly the opportunity they need to innovate
unimpeded by the necessary, but annoying processes associated with a single
centralized repository. This is really no different from people modifying
Buildr for their own needs, except that these modifications can be pushed
back to the community with a minimum of fuss. Eventually, they may find
their way back to the authoritative repo, but in the meantime, there is no
reason why those at the "town-hall" can't reap the benefits and further
their development.
Daniel
On Mon, Mar 2, 2009 at 11:44 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On Mon, Mar 2, 2009 at 7:57 AM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > Welcome back from lurk-mode! :-)
> >
> > I think this is an interesting issue beyond just Git vs SVN and how the
> > project is hosted. As Assaf said, the Git repository is still synced to
> > the
> > SVN (and vice versa), so there isn't any real side-stepping going on. In
> > fact, committers could use SVN directly if they so choose (without any
> > negative impact on an SVN-based workflow), it's merely personal taste
> which
> > drives everyone to Git. The interesting point though is that while in
> > incubation, Vic's GitHub repo really became the "unofficially canonical"
> > one. While Buildr's site did point everyone to the SVN *first*, the
> > culture
> > was such that Git was really the convention/standard across the board.
> > That's not to say that SVN was discouraged in any way, it just wasn't
> used
> > (except as the main store-point once commits were made).
> >
> > The larger issue here is what does it mean to be the "primary" source
> when
> > all sources give the same artifacts? Is it the repository officially
> > recommended by the project? Is it the repository decided by the "wisdom
> of
> > the masses" in the development team? As solutions like Git, Mercurial
> and
> > Bazaar catch on, I think we're going to see more and more projects
> raising
> > this issue: what does it mean to have multiple "canonical" sources and
> when
> > does it really cause problems?
>
>
> Apache has two interesting principles.
>
> The first, you need a "licensed and reviewed contributions" repository. The
> repository blessed by Apache so to speak, from which you cut releases.
> There's a lot of wisdom of the years insisting on having this repository,
> and also insisting that it run on Apache hardware (meaning, guarded and
> monitored by Apache).
>
> The second, all development have to be done in the open, that way everyone
> can participate. It's the open development part of open source. (The
> context
> here is the project and its community, not anything you do downstream.)
> Once
> code has been brought to our attention -- JIRA patch, mailing list
> discussions, etc -- we continue working on it in a public forum with as
> much
> visibility as possible.
>
>
>
> In the SVN model this job is handled by the master repository, but what
> would we do if there was only Git?
>
> You will still have one "licensed and reviewed contributions" Git
> repository, and it will still be hosted on Apache hardware, and it will
> still be only writable to committers. Again all those wisdoms of the years
> will take us there. The difference is, you can also have any number of
> perfectly synchronized clones, so development can happen elsewhere.
>
> Now we get into the open development question. If development can happen
> anywhere, how do I keep track of all the places where it happens? And where
> do I find one place where it happens, so I can start tracking it? You need
> to have at least one place that everyone can point to, a common ground, and
> it needs to have certain guarantees: be an accurate clone of the
> contribution repo, get synchronized quickly enough, not be the weakest link
> (security wise), etc.
>
> It doesn't have to be a single place, but having too many places could be a
> problem. Where do you start? Are they all as well maintained? Will they
> last
> long enough to be permalinks?
>
> The second question is, once code has been brought to our attention, what
> places do we have to accommodate it before it ends up in
> the contribution repo. Our focus here is for everyone to be able to follow
> changes to that code, say as a result of discussion on the mailing list,
> and
> for committers to be able to pull it in as a contribution. This should be
> at
> least as good as what we have right now; for the record, what we have right
> now are JIRA patches.
>
>
>
> In my experience, you can have as many canonical sources as you want, but
> as
> a project you're responsible for their quality/reliability, it actually
> works better to have as few as possible. One must be the "licensed and
> reviewed contribution" repo, which Apache takes care of.
>
> For people who want to track development, view the source code, branch off,
> or start contributing, which repository would you point them to? Let's call
> this one "the town hall repo", the one place we get to socialize around
> code.
>
> I absolutely agree that this should be a decision for the individual
> project. It doesn't have to run on Apache infrastructure, as long as it
> follows certain guidelines (public access, restricted writes, timely
> updates, etc), it just has to work very well for that project. It therefore
> can't be Apache official repository because the ASF can't govern other
> people's infrastructure. But if the project agrees to supervise it for the
> purposes I outlined above, why can't it be the project's primary public
> repository?
>
> To put it in context, all mailing list discussions have to pass through
> Apache's servers, and Apache maintains the contributing archive. If in
> doubt, look there. But projects can tell people to search in other
> archives,
> like markmail or nabble. Can one of these off-site archives be the primary
> point of reference for the project? If so, why can't we do the same for
> source control?
>
> Assaf
>
>
> > Daniel
> >
> > On Mon, Mar 2, 2009 at 3:07 AM, Martijn Dashorst <
> > martijn.dashorst@gmail.com
> > > wrote:
> >
> > > On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
> > > > I'm with you in using Github as the main repository:
> > >
> > > As an ASF Member I must protest against the direction that you are
> > > taking this project. GitHub can not be used as the main repository for
> > > any ASF Project. The canonical resource for Apache project's code must
> > > be hosted on Apache hardware. Since the only repository that is
> > > supported by Infrastructure is SVN, you'll have to maintain the
> > > primary source for your project *in* SVN. Not somewhere else, not
> > > bypassing ASF authorizations, not bypassing Apache policy.
> > >
> > > Martijn
> > >
> >
>
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Mon, Mar 2, 2009 at 7:57 AM, Daniel Spiewak <dj...@gmail.com> wrote:
> Welcome back from lurk-mode! :-)
>
> I think this is an interesting issue beyond just Git vs SVN and how the
> project is hosted. As Assaf said, the Git repository is still synced to
> the
> SVN (and vice versa), so there isn't any real side-stepping going on. In
> fact, committers could use SVN directly if they so choose (without any
> negative impact on an SVN-based workflow), it's merely personal taste which
> drives everyone to Git. The interesting point though is that while in
> incubation, Vic's GitHub repo really became the "unofficially canonical"
> one. While Buildr's site did point everyone to the SVN *first*, the
> culture
> was such that Git was really the convention/standard across the board.
> That's not to say that SVN was discouraged in any way, it just wasn't used
> (except as the main store-point once commits were made).
>
> The larger issue here is what does it mean to be the "primary" source when
> all sources give the same artifacts? Is it the repository officially
> recommended by the project? Is it the repository decided by the "wisdom of
> the masses" in the development team? As solutions like Git, Mercurial and
> Bazaar catch on, I think we're going to see more and more projects raising
> this issue: what does it mean to have multiple "canonical" sources and when
> does it really cause problems?
Apache has two interesting principles.
The first, you need a "licensed and reviewed contributions" repository. The
repository blessed by Apache so to speak, from which you cut releases.
There's a lot of wisdom of the years insisting on having this repository,
and also insisting that it run on Apache hardware (meaning, guarded and
monitored by Apache).
The second, all development have to be done in the open, that way everyone
can participate. It's the open development part of open source. (The context
here is the project and its community, not anything you do downstream.) Once
code has been brought to our attention -- JIRA patch, mailing list
discussions, etc -- we continue working on it in a public forum with as much
visibility as possible.
In the SVN model this job is handled by the master repository, but what
would we do if there was only Git?
You will still have one "licensed and reviewed contributions" Git
repository, and it will still be hosted on Apache hardware, and it will
still be only writable to committers. Again all those wisdoms of the years
will take us there. The difference is, you can also have any number of
perfectly synchronized clones, so development can happen elsewhere.
Now we get into the open development question. If development can happen
anywhere, how do I keep track of all the places where it happens? And where
do I find one place where it happens, so I can start tracking it? You need
to have at least one place that everyone can point to, a common ground, and
it needs to have certain guarantees: be an accurate clone of the
contribution repo, get synchronized quickly enough, not be the weakest link
(security wise), etc.
It doesn't have to be a single place, but having too many places could be a
problem. Where do you start? Are they all as well maintained? Will they last
long enough to be permalinks?
The second question is, once code has been brought to our attention, what
places do we have to accommodate it before it ends up in
the contribution repo. Our focus here is for everyone to be able to follow
changes to that code, say as a result of discussion on the mailing list, and
for committers to be able to pull it in as a contribution. This should be at
least as good as what we have right now; for the record, what we have right
now are JIRA patches.
In my experience, you can have as many canonical sources as you want, but as
a project you're responsible for their quality/reliability, it actually
works better to have as few as possible. One must be the "licensed and
reviewed contribution" repo, which Apache takes care of.
For people who want to track development, view the source code, branch off,
or start contributing, which repository would you point them to? Let's call
this one "the town hall repo", the one place we get to socialize around
code.
I absolutely agree that this should be a decision for the individual
project. It doesn't have to run on Apache infrastructure, as long as it
follows certain guidelines (public access, restricted writes, timely
updates, etc), it just has to work very well for that project. It therefore
can't be Apache official repository because the ASF can't govern other
people's infrastructure. But if the project agrees to supervise it for the
purposes I outlined above, why can't it be the project's primary public
repository?
To put it in context, all mailing list discussions have to pass through
Apache's servers, and Apache maintains the contributing archive. If in
doubt, look there. But projects can tell people to search in other archives,
like markmail or nabble. Can one of these off-site archives be the primary
point of reference for the project? If so, why can't we do the same for
source control?
Assaf
> Daniel
>
> On Mon, Mar 2, 2009 at 3:07 AM, Martijn Dashorst <
> martijn.dashorst@gmail.com
> > wrote:
>
> > On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
> > > I'm with you in using Github as the main repository:
> >
> > As an ASF Member I must protest against the direction that you are
> > taking this project. GitHub can not be used as the main repository for
> > any ASF Project. The canonical resource for Apache project's code must
> > be hosted on Apache hardware. Since the only repository that is
> > supported by Infrastructure is SVN, you'll have to maintain the
> > primary source for your project *in* SVN. Not somewhere else, not
> > bypassing ASF authorizations, not bypassing Apache policy.
> >
> > Martijn
> >
>
Re: Welcome to Rebase Hell!
Posted by Alex Boisvert <bo...@intalio.com>.
On Mon, Mar 2, 2009 at 7:57 AM, Daniel Spiewak <dj...@gmail.com> wrote:
> I think this is an interesting issue beyond just Git vs SVN and how the
> project is hosted. As Assaf said, the Git repository is still synced to
> the
> SVN (and vice versa), so there isn't any real side-stepping going on. In
> fact, committers could use SVN directly if they so choose (without any
> negative impact on an SVN-based workflow), it's merely personal taste which
> drives everyone to Git. The interesting point though is that while in
> incubation, Vic's GitHub repo really became the "unofficially canonical"
> one. While Buildr's site did point everyone to the SVN *first*, the
> culture
> was such that Git was really the convention/standard across the board.
> That's not to say that SVN was discouraged in any way, it just wasn't used
> (except as the main store-point once commits were made).
Actually, the Subversion repository was used directly. By myself and others
for sure based on patches we've received.
We have to be very clear that the official repository remains the Apache
Subversion repository (at least until we get proper infrastructure for Git
at Apache). All the Git / Github integration is provided for convenience,
This being said, having a designated Git repository (I'm trying not to use
the word official) makes everybody's life easier because it reduces rebase
hell. So I think the confusion here is between official -- as in Apache
official -- and designated -- as in this is what the Buildr community
recommends if you're using Git.
The repository of reference remains at Apache and this is what is used to
cut any Apache releases. No question about that.
alex
Re: Welcome to Rebase Hell!
Posted by Daniel Spiewak <dj...@gmail.com>.
Welcome back from lurk-mode! :-)
I think this is an interesting issue beyond just Git vs SVN and how the
project is hosted. As Assaf said, the Git repository is still synced to the
SVN (and vice versa), so there isn't any real side-stepping going on. In
fact, committers could use SVN directly if they so choose (without any
negative impact on an SVN-based workflow), it's merely personal taste which
drives everyone to Git. The interesting point though is that while in
incubation, Vic's GitHub repo really became the "unofficially canonical"
one. While Buildr's site did point everyone to the SVN *first*, the culture
was such that Git was really the convention/standard across the board.
That's not to say that SVN was discouraged in any way, it just wasn't used
(except as the main store-point once commits were made).
The larger issue here is what does it mean to be the "primary" source when
all sources give the same artifacts? Is it the repository officially
recommended by the project? Is it the repository decided by the "wisdom of
the masses" in the development team? As solutions like Git, Mercurial and
Bazaar catch on, I think we're going to see more and more projects raising
this issue: what does it mean to have multiple "canonical" sources and when
does it really cause problems?
Daniel
On Mon, Mar 2, 2009 at 3:07 AM, Martijn Dashorst <martijn.dashorst@gmail.com
> wrote:
> On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
> > I'm with you in using Github as the main repository:
>
> As an ASF Member I must protest against the direction that you are
> taking this project. GitHub can not be used as the main repository for
> any ASF Project. The canonical resource for Apache project's code must
> be hosted on Apache hardware. Since the only repository that is
> supported by Infrastructure is SVN, you'll have to maintain the
> primary source for your project *in* SVN. Not somewhere else, not
> bypassing ASF authorizations, not bypassing Apache policy.
>
> Martijn
>
Re: Welcome to Rebase Hell!
Posted by Martijn Dashorst <ma...@gmail.com>.
On Mon, Mar 2, 2009 at 1:34 AM, Assaf Arkin <ar...@intalio.com> wrote:
> I'm with you in using Github as the main repository:
As an ASF Member I must protest against the direction that you are
taking this project. GitHub can not be used as the main repository for
any ASF Project. The canonical resource for Apache project's code must
be hosted on Apache hardware. Since the only repository that is
supported by Infrastructure is SVN, you'll have to maintain the
primary source for your project *in* SVN. Not somewhere else, not
bypassing ASF authorizations, not bypassing Apache policy.
Martijn
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Sun, Mar 1, 2009 at 4:57 AM, Victor Hugo Borja <vi...@gmail.com>wrote:
> I guess Buildr was one of the first Apache projects using git for
> development. Our github mirror at vic/buildr from incubation days was
> created from svn.apache.org server, and as Assaf mentions, TLP there seems
> to be some restrictions on using git-svn on asf/ directory level on that
> server, so our best bet would be to use eu.svn..
>
> One issue is duplication of commits history because Git uses the author
> name/email to create the hash for a commit. Actually we faced this problem
> back early when we started playing with git, a bare git-svn clone from
> svn.apache.org would have git-svn generated user name/email for the commit
> hash. When we pushed into github, we did using our real name and the email
> address we were using for our github account. That caused our commit
> history
> duplication due to having different user info on each commit, we kinda
> solved it using a etc/git-svn-authors file so that git-svn could know which
> apache account mapped to github accounts.
>
> Now, we could easily use Jukka's git mirror[1] but we have some issues to
> solve.. Jukka's mirror was created by a bare git-svn checkout (yet it uses
> our real user names and apache addrs), so if we push these commits to
> github
> we would have again a duplication of commit history, because commits on
> Jukka's mirror have been signed with our apache account and know nothing
> about github (doesn't use etc/git-svn-authors).
>
> I'd propose using [1] and push a fresh clone from it to vic/buildr. Using
> GitHub IMHO has many advantages over just using [1], first is we have more
> control over when to update the mirror with current branch, and can keep it
> more up-to-date if needed, we can push directly to it, and easily use the
> fork queue to integrate other's changes. In doing this we (buildr commiters
> using github) would need to make some changes..
>
> - Get a fresh clone from [1] and cd into it
> - Use your apache account to git push (would have done this from the
> beginning)
> git config user.email you@apache.org
> add you@apache.org on your github account so it can recognize changes
> made by you.
> - Now the tedious thing would be to get changes from your experimental
> branches into your new clone without having duplicate commits.
> - I would update git-svn-authors to use our apache email addresses, and
> also update the buildr-git to use eu.svn as [1] does.
>
> What you think about this?
We can use this author list:
http://people.apache.org/~jukka/authors.txt
I'm with you in using Github as the main repository:
1. Good UI for tracking commits, navigating the tree, code review, etc, even
if not using the Git part of it.
2. You had vic/buildr synchronizing against SVN within the hour.
3. Anyone can get a free account, fork Buildr with a click, use it to share
their work.
Assaf
>
> [1] http://jukka.zitting.name/git/?p=buildr.git;a=summary
> --
> vic
>
> Quaerendo invenietis.
>
Re: Welcome to Rebase Hell!
Posted by Victor Hugo Borja <vi...@gmail.com>.
I guess Buildr was one of the first Apache projects using git for
development. Our github mirror at vic/buildr from incubation days was
created from svn.apache.org server, and as Assaf mentions, TLP there seems
to be some restrictions on using git-svn on asf/ directory level on that
server, so our best bet would be to use eu.svn..
One issue is duplication of commits history because Git uses the author
name/email to create the hash for a commit. Actually we faced this problem
back early when we started playing with git, a bare git-svn clone from
svn.apache.org would have git-svn generated user name/email for the commit
hash. When we pushed into github, we did using our real name and the email
address we were using for our github account. That caused our commit history
duplication due to having different user info on each commit, we kinda
solved it using a etc/git-svn-authors file so that git-svn could know which
apache account mapped to github accounts.
Now, we could easily use Jukka's git mirror[1] but we have some issues to
solve.. Jukka's mirror was created by a bare git-svn checkout (yet it uses
our real user names and apache addrs), so if we push these commits to github
we would have again a duplication of commit history, because commits on
Jukka's mirror have been signed with our apache account and know nothing
about github (doesn't use etc/git-svn-authors).
I'd propose using [1] and push a fresh clone from it to vic/buildr. Using
GitHub IMHO has many advantages over just using [1], first is we have more
control over when to update the mirror with current branch, and can keep it
more up-to-date if needed, we can push directly to it, and easily use the
fork queue to integrate other's changes. In doing this we (buildr commiters
using github) would need to make some changes..
- Get a fresh clone from [1] and cd into it
- Use your apache account to git push (would have done this from the
beginning)
git config user.email you@apache.org
add you@apache.org on your github account so it can recognize changes
made by you.
- Now the tedious thing would be to get changes from your experimental
branches into your new clone without having duplicate commits.
- I would update git-svn-authors to use our apache email addresses, and
also update the buildr-git to use eu.svn as [1] does.
What you think about this?
[1] http://jukka.zitting.name/git/?p=buildr.git;a=summary
--
vic
Quaerendo invenietis.
Re: Welcome to Rebase Hell!
Posted by Daniel Spiewak <dj...@gmail.com>.
> PS: I merged your "separate-scala-specs" branch so no need to sweat
> through
> that one.
Cool! Did you get some of the more recent changes (documentation and RSpec
specs)? I think I may have also changed some behavior somewhere to be more
in-line with how Buildr's other test frameworks behave (probably failure).
Daniel
Re: Welcome to Rebase Hell!
Posted by Alex Boisvert <bo...@intalio.com>.
I'll simply quote Assaf from a few weeks ago:
"Git-svn is the worse of Git and the worse of SVN"
I have very low expectations that we'll find a suitable solution until we
officially migrate to Git at Apache. Personally, I'm through playing merge
roulette with git-svn...
alex
PS: I merged your "separate-scala-specs" branch so no need to sweat through
that one.
On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> Those of you following development progress using Git are probably starting
> to notice that the classical "Vic Master" is no longer the all-knowing
> source of data. Actually, Assaf's GitHub fork has become the more
> trustworthy one. This is because upon its exit from incubation, Buildr
> gets
> to move its SVN repository to a new URL. This is good for the project, but
> bad for the Git forks since git-svn stores the URL information in its
> commit
> messages.
>
> The solution of course is to re-clone from SVN, which I assume exactly what
> Assaf did. There result is a repository which contains all of the same SVN
> commits as Vic's, but different messages and very different SHA1 revisions,
> meaning that Git has a much harder time merging between the two. I
> discovered this when I attempted to merge Assaf's latest changes with my
> master (forked from Vic's). 57 conflicts later (all petty, little issues
> unrelated to my additions), I finally had a working master with the latest
> commits. Unfortunately, when I cloned Assaf's repository directly and
> attempted to merge back some of my changes, it became very apparent that I
> would need to fix the issue in a more scientific manner.
>
> Long story short, the solution is to rebase all of your branches onto
> Assaf's master. I did this by finding the exact commit where I diverged
> from vic (I had it tagged, actually) as well as the corresponding commit in
> Assaf's master. These commits I tagged "branch-point" and
> "new-branch-point", respectively. Then for each branch, I did something
> like the following:
>
> git checkout scala-joint-compilation
> git rebase new-branch-point
>
> Once this was done, I went back to my master and performed a similar
> procedure:
>
> git checkout master
> git rebase -s ours new-branch-point
>
> This effectively wiped out all of my changes in that branch (it's possible
> that some commits may remain if you try it, but none did in my case). Once
> this was done, I went and picked through my origin/master log to see what I
> was missing. This meant re-merging all of my branches:
>
> git merge scala-joint-compilation
> git merge clojure
> ...
>
> Also, I had to cherry-pick a few commits that I had done on master (like
> four or five):
>
> git cherry-pick all-your-ant-base
> ...
>
> Once this was done, I pushed the result back to GitHub:
>
> git push -f origin
>
> The one caveat to this approach is I had all of my changes on numerous
> separate branches (for patching reasons). All of these branches were
> branched off of the same point on vic/master. Since there hadn't been any
> merging *between* the branches (only onto master), it was fairly easy to
> just rebase these branches onto the new trunk (I only had three conflicts
> in
> the whole process, all easily resolved). Just judging by GitHub, not many
> people are managing their repositories in this fashion. However, this does
> mean that you could be able to just rebase without the "-s ours" on your
> master and come to the same result.
>
> The point is that you will need to perform some conniptions of this sort in
> order to fix your repositories, otherwise your changes will remain
> incompatible with the Buildr mainline trunk: you won't be able to (easily)
> merge assaf/master, and he won't be able to (easily) pull from you.
>
> Incidentally, if anyone has a *better* way of doing this (particularly one
> where the entire master history doesn't get wiped out), I'm all ears! I do
> still have the unmerged repository sitting in Time Machine, so I'm
> perfectly
> willing to roll-forward a copy and try again if the result turns out to be
> more correct.
>
> Daniel
>
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Sat, Feb 28, 2009 at 11:47 PM, Alexis Midon <al...@gmail.com>wrote:
> Disclaimer: I haven't read all the details of these long emails so I
> apologize if I'm out of topic.
>
> If you need a git clone freshly synchronized with svn, jukka's clones are
> updated daily and could be updated per commit. Yo could easily pull from
> there, then push to github.
> http://jukka.zitting.name/git/
>
Jukka's is chronically late, at best 4 hours behind SVN, sometimes
stretching into days.
Right now it reports the most recent change being OpenJPA 5 hours ago. If
Apache SVN goes five hours without a commit, something big is happening in
the world, but CNN reports nothing out of the ordinary.
In fact, SVN happily reports a Maven update 2 minutes ago (Jukka's at 13
hours), and Spam Assassin 18 minutes ago (Jukka's at 24 hours).
Of course, if you just want to catch up to head and rebase/merge
occasionally, 4~24 hour delay is not a deal killer. But it does get annoying
when someone commits your patch to trunk, or makes a change you want to
test, and you can't fetch it until the next day.
Which is one reason I did not update the Git portion of the documentation
yet. We still don't have a recommended repo to clone.
Assaf
> <http://jukka.zitting.name/git/>
>
> Alexis
>
>
> On Sat, Feb 28, 2009 at 11:02 PM, Daniel Spiewak <djspiewak@gmail.com
> >wrote:
>
> > Actually, I don't think that it is a restriction that Apache has placed
> on
> > their SVN server (AFAIK). The way that git-svn works is it grabs every
> > single change set back to the beginning of time. This means a really, *
> > really* huge checkout from the server, all at once. While this is not
> > strictly a problem for SVN, it does pose some issues when SVN is being
> run
> > through mod_dav. Basically, mod_svn_dav (or mod_svn, whichever it is)
> > keeps
> > accruing objects in memory as the checkout progresses. At some point,
> the
> > process handling your HTTP request actually crashes because it runs out
> of
> > heap space.
> >
> > I ran into this issue at my previous job, though it would manifest itself
> > as
> > a PROPSET error on svn checkout. Because we had one particularly huge
> > changeset, I was never able to do a full checkout of all revisions from
> > scratch. Using the svn client, things were at least passable (since you
> > could repeatedly "svn up"), but it wasn't pretty. The really depressing
> > thing is that this is a known issue. The mod_dav folks say that it's
> SVN's
> > fault, while the SVN folks keep bouncing the problem back. I've also
> heard
> > it said that no one would ever run into this issue when using SVN
> > "properly", so it's not a serious concern. :-S The officially
> > "workaround"
> > is to just allocate more memory to httpd.
> >
> > I'm not sure why this wouldn't affect incubator, but it may be partially
> > due
> > to the fact that you performed your initial clone of the Buildr repo at a
> > much earlier point than this. Alternatively, there may be some other
> > factors in play here beyond annoying bugs associated with SVN+HTTPS.
> >
> > Daniel
> >
> > On Sun, Mar 1, 2009 at 12:40 AM, Assaf Arkin <ar...@intalio.com> wrote:
> >
> > > On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <dj...@gmail.com>
> > > wrote:
> > >
> > > > Those of you following development progress using Git are probably
> > > starting
> > > > to notice that the classical "Vic Master" is no longer the
> all-knowing
> > > > source of data. Actually, Assaf's GitHub fork has become the more
> > > > trustworthy one. This is because upon its exit from incubation,
> Buildr
> > > > gets
> > > > to move its SVN repository to a new URL. This is good for the
> project,
> > > but
> > > > bad for the Git forks since git-svn stores the URL information in its
> > > > commit
> > > > messages.
> > > >
> > > > The solution of course is to re-clone from SVN, which I assume
> exactly
> > > what
> > > > Assaf did. There result is a repository which contains all of the
> same
> > > SVN
> > > > commits as Vic's, but different messages and very different SHA1
> > > revisions,
> > > > meaning that Git has a much harder time merging between the two. I
> > > > discovered this when I attempted to merge Assaf's latest changes with
> > my
> > > > master (forked from Vic's). 57 conflicts later (all petty, little
> > issues
> > > > unrelated to my additions), I finally had a working master with the
> > > latest
> > > > commits. Unfortunately, when I cloned Assaf's repository directly
> and
> > > > attempted to merge back some of my changes, it became very apparent
> > that
> > > I
> > > > would need to fix the issue in a more scientific manner.
> > > >
> > > > Long story short, the solution is to rebase all of your branches onto
> > > > Assaf's master. I did this by finding the exact commit where I
> > diverged
> > > > from vic (I had it tagged, actually) as well as the corresponding
> > commit
> > > in
> > > > Assaf's master. These commits I tagged "branch-point" and
> > > > "new-branch-point", respectively. Then for each branch, I did
> > something
> > > > like the following:
> > > >
> > > > git checkout scala-joint-compilation
> > > > git rebase new-branch-point
> > > >
> > > > Once this was done, I went back to my master and performed a similar
> > > > procedure:
> > > >
> > > > git checkout master
> > > > git rebase -s ours new-branch-point
> > > >
> > > > This effectively wiped out all of my changes in that branch (it's
> > > possible
> > > > that some commits may remain if you try it, but none did in my case).
> > > Once
> > > > this was done, I went and picked through my origin/master log to see
> > what
> > > I
> > > > was missing. This meant re-merging all of my branches:
> > > >
> > > > git merge scala-joint-compilation
> > > > git merge clojure
> > > > ...
> > > >
> > > > Also, I had to cherry-pick a few commits that I had done on master
> > (like
> > > > four or five):
> > > >
> > > > git cherry-pick all-your-ant-base
> > > > ...
> > > >
> > > > Once this was done, I pushed the result back to GitHub:
> > > >
> > > > git push -f origin
> > > >
> > > > The one caveat to this approach is I had all of my changes on
> numerous
> > > > separate branches (for patching reasons). All of these branches were
> > > > branched off of the same point on vic/master. Since there hadn't
> been
> > > any
> > > > merging *between* the branches (only onto master), it was fairly easy
> > to
> > > > just rebase these branches onto the new trunk (I only had three
> > conflicts
> > > > in
> > > > the whole process, all easily resolved). Just judging by GitHub, not
> > > many
> > > > people are managing their repositories in this fashion. However,
> this
> > > does
> > > > mean that you could be able to just rebase without the "-s ours" on
> > your
> > > > master and come to the same result.
> > > >
> > > > The point is that you will need to perform some conniptions of this
> > sort
> > > in
> > > > order to fix your repositories, otherwise your changes will remain
> > > > incompatible with the Buildr mainline trunk: you won't be able to
> > > (easily)
> > > > merge assaf/master, and he won't be able to (easily) pull from you.
> > > >
> > > > Incidentally, if anyone has a *better* way of doing this
> (particularly
> > > one
> > > > where the entire master history doesn't get wiped out), I'm all ears!
> > I
> > > do
> > > > still have the unmerged repository sitting in Time Machine, so I'm
> > > > perfectly
> > > > willing to roll-forward a copy and try again if the result turns out
> to
> > > be
> > > > more correct.
> > >
> > >
> > > Thanks.
> > >
> > >
> > > AFAIK it's not possible to git svn clone directly from
> svn.apache.orgdue
> > > to
> > > some weird restriction they placed on the SVN server, it will just keep
> > > git-svn hanging forever. Somehow that doesn't affect incubator
> projects,
> > or
> > > svn.eu.apache.org, although my starting point was Jukka's unofficial
> but
> > > somewhat official git mirror[1].
> > >
> > >
> > > When you git log, check the git-svn-id:
> > >
> > > commit a3ab30a66a092bf730950bd95a1394253ebd2f39
> > >
> > > Author: Assaf Arkin <as...@apache.org>
> > >
> > > Date: Fri Feb 27 22:24:50 2009 +0000
> > >
> > >
> > > > Fixed RDoc 2.3/2.4 conflict on rake setup.
> > >
> > >
> > >
> > > git-svn-id:
> > >
> > >
> >
> https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68
> > >
> > >
> > > If two repositories use a different URL -- look for http vs https,
> > > svn.eu.apache.org vs svn.apache.org, asf/buildr vs
> asf/incubator/buildr
> > --
> > > Git considers them distinct trees (branches). Any time you merge, Git
> > will
> > > have to merge the entire history of these two branches, leading to a
> lot
> > of
> > > conflicts.
> > >
> > > So if you have branches with changes, follow Daniel's instructions. If
> > you
> > > don't, you can still use the -s ours strategy to "switch" from one
> branch
> > > to
> > > another.
> > >
> > > Until Apache comes with a better solution, I'm going to keep my
> > > repository synchronized against
> > > https://svn.eu.apache.org/repos/asf/buildr.
> > > I suggest you all do the same, that way we have the same history and
> can
> > > easily merge with each other.
> > >
> > > Assaf
> > >
> > > [1] http://jukka.zitting.name/git/
> > >
> > >
> > >
> > > >
> > > >
> > > > Daniel
> > > >
> > >
> >
>
Re: Welcome to Rebase Hell!
Posted by Alexis Midon <al...@gmail.com>.
Disclaimer: I haven't read all the details of these long emails so I
apologize if I'm out of topic.
If you need a git clone freshly synchronized with svn, jukka's clones are
updated daily and could be updated per commit. Yo could easily pull from
there, then push to github.
http://jukka.zitting.name/git/
Alexis
On Sat, Feb 28, 2009 at 11:02 PM, Daniel Spiewak <dj...@gmail.com>wrote:
> Actually, I don't think that it is a restriction that Apache has placed on
> their SVN server (AFAIK). The way that git-svn works is it grabs every
> single change set back to the beginning of time. This means a really, *
> really* huge checkout from the server, all at once. While this is not
> strictly a problem for SVN, it does pose some issues when SVN is being run
> through mod_dav. Basically, mod_svn_dav (or mod_svn, whichever it is)
> keeps
> accruing objects in memory as the checkout progresses. At some point, the
> process handling your HTTP request actually crashes because it runs out of
> heap space.
>
> I ran into this issue at my previous job, though it would manifest itself
> as
> a PROPSET error on svn checkout. Because we had one particularly huge
> changeset, I was never able to do a full checkout of all revisions from
> scratch. Using the svn client, things were at least passable (since you
> could repeatedly "svn up"), but it wasn't pretty. The really depressing
> thing is that this is a known issue. The mod_dav folks say that it's SVN's
> fault, while the SVN folks keep bouncing the problem back. I've also heard
> it said that no one would ever run into this issue when using SVN
> "properly", so it's not a serious concern. :-S The officially
> "workaround"
> is to just allocate more memory to httpd.
>
> I'm not sure why this wouldn't affect incubator, but it may be partially
> due
> to the fact that you performed your initial clone of the Buildr repo at a
> much earlier point than this. Alternatively, there may be some other
> factors in play here beyond annoying bugs associated with SVN+HTTPS.
>
> Daniel
>
> On Sun, Mar 1, 2009 at 12:40 AM, Assaf Arkin <ar...@intalio.com> wrote:
>
> > On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> >
> > > Those of you following development progress using Git are probably
> > starting
> > > to notice that the classical "Vic Master" is no longer the all-knowing
> > > source of data. Actually, Assaf's GitHub fork has become the more
> > > trustworthy one. This is because upon its exit from incubation, Buildr
> > > gets
> > > to move its SVN repository to a new URL. This is good for the project,
> > but
> > > bad for the Git forks since git-svn stores the URL information in its
> > > commit
> > > messages.
> > >
> > > The solution of course is to re-clone from SVN, which I assume exactly
> > what
> > > Assaf did. There result is a repository which contains all of the same
> > SVN
> > > commits as Vic's, but different messages and very different SHA1
> > revisions,
> > > meaning that Git has a much harder time merging between the two. I
> > > discovered this when I attempted to merge Assaf's latest changes with
> my
> > > master (forked from Vic's). 57 conflicts later (all petty, little
> issues
> > > unrelated to my additions), I finally had a working master with the
> > latest
> > > commits. Unfortunately, when I cloned Assaf's repository directly and
> > > attempted to merge back some of my changes, it became very apparent
> that
> > I
> > > would need to fix the issue in a more scientific manner.
> > >
> > > Long story short, the solution is to rebase all of your branches onto
> > > Assaf's master. I did this by finding the exact commit where I
> diverged
> > > from vic (I had it tagged, actually) as well as the corresponding
> commit
> > in
> > > Assaf's master. These commits I tagged "branch-point" and
> > > "new-branch-point", respectively. Then for each branch, I did
> something
> > > like the following:
> > >
> > > git checkout scala-joint-compilation
> > > git rebase new-branch-point
> > >
> > > Once this was done, I went back to my master and performed a similar
> > > procedure:
> > >
> > > git checkout master
> > > git rebase -s ours new-branch-point
> > >
> > > This effectively wiped out all of my changes in that branch (it's
> > possible
> > > that some commits may remain if you try it, but none did in my case).
> > Once
> > > this was done, I went and picked through my origin/master log to see
> what
> > I
> > > was missing. This meant re-merging all of my branches:
> > >
> > > git merge scala-joint-compilation
> > > git merge clojure
> > > ...
> > >
> > > Also, I had to cherry-pick a few commits that I had done on master
> (like
> > > four or five):
> > >
> > > git cherry-pick all-your-ant-base
> > > ...
> > >
> > > Once this was done, I pushed the result back to GitHub:
> > >
> > > git push -f origin
> > >
> > > The one caveat to this approach is I had all of my changes on numerous
> > > separate branches (for patching reasons). All of these branches were
> > > branched off of the same point on vic/master. Since there hadn't been
> > any
> > > merging *between* the branches (only onto master), it was fairly easy
> to
> > > just rebase these branches onto the new trunk (I only had three
> conflicts
> > > in
> > > the whole process, all easily resolved). Just judging by GitHub, not
> > many
> > > people are managing their repositories in this fashion. However, this
> > does
> > > mean that you could be able to just rebase without the "-s ours" on
> your
> > > master and come to the same result.
> > >
> > > The point is that you will need to perform some conniptions of this
> sort
> > in
> > > order to fix your repositories, otherwise your changes will remain
> > > incompatible with the Buildr mainline trunk: you won't be able to
> > (easily)
> > > merge assaf/master, and he won't be able to (easily) pull from you.
> > >
> > > Incidentally, if anyone has a *better* way of doing this (particularly
> > one
> > > where the entire master history doesn't get wiped out), I'm all ears!
> I
> > do
> > > still have the unmerged repository sitting in Time Machine, so I'm
> > > perfectly
> > > willing to roll-forward a copy and try again if the result turns out to
> > be
> > > more correct.
> >
> >
> > Thanks.
> >
> >
> > AFAIK it's not possible to git svn clone directly from svn.apache.orgdue
> > to
> > some weird restriction they placed on the SVN server, it will just keep
> > git-svn hanging forever. Somehow that doesn't affect incubator projects,
> or
> > svn.eu.apache.org, although my starting point was Jukka's unofficial but
> > somewhat official git mirror[1].
> >
> >
> > When you git log, check the git-svn-id:
> >
> > commit a3ab30a66a092bf730950bd95a1394253ebd2f39
> >
> > Author: Assaf Arkin <as...@apache.org>
> >
> > Date: Fri Feb 27 22:24:50 2009 +0000
> >
> >
> > > Fixed RDoc 2.3/2.4 conflict on rake setup.
> >
> >
> >
> > git-svn-id:
> >
> >
> https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68
> >
> >
> > If two repositories use a different URL -- look for http vs https,
> > svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr
> --
> > Git considers them distinct trees (branches). Any time you merge, Git
> will
> > have to merge the entire history of these two branches, leading to a lot
> of
> > conflicts.
> >
> > So if you have branches with changes, follow Daniel's instructions. If
> you
> > don't, you can still use the -s ours strategy to "switch" from one branch
> > to
> > another.
> >
> > Until Apache comes with a better solution, I'm going to keep my
> > repository synchronized against
> > https://svn.eu.apache.org/repos/asf/buildr.
> > I suggest you all do the same, that way we have the same history and can
> > easily merge with each other.
> >
> > Assaf
> >
> > [1] http://jukka.zitting.name/git/
> >
> >
> >
> > >
> > >
> > > Daniel
> > >
> >
>
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Sat, Feb 28, 2009 at 11:02 PM, Daniel Spiewak <dj...@gmail.com>wrote:
> Actually, I don't think that it is a restriction that Apache has placed on
> their SVN server (AFAIK). The way that git-svn works is it grabs every
> single change set back to the beginning of time. This means a really, *
> really* huge checkout from the server, all at once. While this is not
> strictly a problem for SVN, it does pose some issues when SVN is being run
> through mod_dav. Basically, mod_svn_dav (or mod_svn, whichever it is)
> keeps
> accruing objects in memory as the checkout progresses. At some point, the
> process handling your HTTP request actually crashes because it runs out of
> heap space.
>
> I ran into this issue at my previous job, though it would manifest itself
> as
> a PROPSET error on svn checkout. Because we had one particularly huge
> changeset, I was never able to do a full checkout of all revisions from
> scratch. Using the svn client, things were at least passable (since you
> could repeatedly "svn up"), but it wasn't pretty. The really depressing
> thing is that this is a known issue. The mod_dav folks say that it's SVN's
> fault, while the SVN folks keep bouncing the problem back. I've also heard
> it said that no one would ever run into this issue when using SVN
> "properly", so it's not a serious concern. :-S The officially
> "workaround"
> is to just allocate more memory to httpd.
>
> I'm not sure why this wouldn't affect incubator, but it may be partially
> due
> to the fact that you performed your initial clone of the Buildr repo at a
> much earlier point than this. Alternatively, there may be some other
> factors in play here beyond annoying bugs associated with SVN+HTTPS.
Apache has one repository shared by all the projects, the first Buildr
commit was made at rev 591150 (we're now at 748722). So even on day one, you
have to go through half a million commits before you get to the first line
of Buildr code.
The only way to have git-svn complete in a life time is to select a specific
version to start with (-r) and then grab the rest with git fetch, which is
pretty snappy. So starting with rev 594940, you can quickly clone incubator:
git svn clone
https://svn.apache.org/repos/asf/incubator/buildr/--revision 594940
But you can't clone trunk from the top-level Buildr, this will fail:
git svn clone https://svn.apache.org/repos/asf/buildr/ --revision 594940
Same thing happens with sandboxes, you can clone a sandbox (say
/asf/buildr/sandbox/cool-new-stuff) but not the top-level projects, so
something tells me paths immediately under /asf/ are blocked.
Assaf
>
>
> Daniel
>
> On Sun, Mar 1, 2009 at 12:40 AM, Assaf Arkin <ar...@intalio.com> wrote:
>
> > On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <dj...@gmail.com>
> > wrote:
> >
> > > Those of you following development progress using Git are probably
> > starting
> > > to notice that the classical "Vic Master" is no longer the all-knowing
> > > source of data. Actually, Assaf's GitHub fork has become the more
> > > trustworthy one. This is because upon its exit from incubation, Buildr
> > > gets
> > > to move its SVN repository to a new URL. This is good for the project,
> > but
> > > bad for the Git forks since git-svn stores the URL information in its
> > > commit
> > > messages.
> > >
> > > The solution of course is to re-clone from SVN, which I assume exactly
> > what
> > > Assaf did. There result is a repository which contains all of the same
> > SVN
> > > commits as Vic's, but different messages and very different SHA1
> > revisions,
> > > meaning that Git has a much harder time merging between the two. I
> > > discovered this when I attempted to merge Assaf's latest changes with
> my
> > > master (forked from Vic's). 57 conflicts later (all petty, little
> issues
> > > unrelated to my additions), I finally had a working master with the
> > latest
> > > commits. Unfortunately, when I cloned Assaf's repository directly and
> > > attempted to merge back some of my changes, it became very apparent
> that
> > I
> > > would need to fix the issue in a more scientific manner.
> > >
> > > Long story short, the solution is to rebase all of your branches onto
> > > Assaf's master. I did this by finding the exact commit where I
> diverged
> > > from vic (I had it tagged, actually) as well as the corresponding
> commit
> > in
> > > Assaf's master. These commits I tagged "branch-point" and
> > > "new-branch-point", respectively. Then for each branch, I did
> something
> > > like the following:
> > >
> > > git checkout scala-joint-compilation
> > > git rebase new-branch-point
> > >
> > > Once this was done, I went back to my master and performed a similar
> > > procedure:
> > >
> > > git checkout master
> > > git rebase -s ours new-branch-point
> > >
> > > This effectively wiped out all of my changes in that branch (it's
> > possible
> > > that some commits may remain if you try it, but none did in my case).
> > Once
> > > this was done, I went and picked through my origin/master log to see
> what
> > I
> > > was missing. This meant re-merging all of my branches:
> > >
> > > git merge scala-joint-compilation
> > > git merge clojure
> > > ...
> > >
> > > Also, I had to cherry-pick a few commits that I had done on master
> (like
> > > four or five):
> > >
> > > git cherry-pick all-your-ant-base
> > > ...
> > >
> > > Once this was done, I pushed the result back to GitHub:
> > >
> > > git push -f origin
> > >
> > > The one caveat to this approach is I had all of my changes on numerous
> > > separate branches (for patching reasons). All of these branches were
> > > branched off of the same point on vic/master. Since there hadn't been
> > any
> > > merging *between* the branches (only onto master), it was fairly easy
> to
> > > just rebase these branches onto the new trunk (I only had three
> conflicts
> > > in
> > > the whole process, all easily resolved). Just judging by GitHub, not
> > many
> > > people are managing their repositories in this fashion. However, this
> > does
> > > mean that you could be able to just rebase without the "-s ours" on
> your
> > > master and come to the same result.
> > >
> > > The point is that you will need to perform some conniptions of this
> sort
> > in
> > > order to fix your repositories, otherwise your changes will remain
> > > incompatible with the Buildr mainline trunk: you won't be able to
> > (easily)
> > > merge assaf/master, and he won't be able to (easily) pull from you.
> > >
> > > Incidentally, if anyone has a *better* way of doing this (particularly
> > one
> > > where the entire master history doesn't get wiped out), I'm all ears!
> I
> > do
> > > still have the unmerged repository sitting in Time Machine, so I'm
> > > perfectly
> > > willing to roll-forward a copy and try again if the result turns out to
> > be
> > > more correct.
> >
> >
> > Thanks.
> >
> >
> > AFAIK it's not possible to git svn clone directly from svn.apache.orgdue
> > to
> > some weird restriction they placed on the SVN server, it will just keep
> > git-svn hanging forever. Somehow that doesn't affect incubator projects,
> or
> > svn.eu.apache.org, although my starting point was Jukka's unofficial but
> > somewhat official git mirror[1].
> >
> >
> > When you git log, check the git-svn-id:
> >
> > commit a3ab30a66a092bf730950bd95a1394253ebd2f39
> >
> > Author: Assaf Arkin <as...@apache.org>
> >
> > Date: Fri Feb 27 22:24:50 2009 +0000
> >
> >
> > > Fixed RDoc 2.3/2.4 conflict on rake setup.
> >
> >
> >
> > git-svn-id:
> >
> >
> https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68
> >
> >
> > If two repositories use a different URL -- look for http vs https,
> > svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr
> --
> > Git considers them distinct trees (branches). Any time you merge, Git
> will
> > have to merge the entire history of these two branches, leading to a lot
> of
> > conflicts.
> >
> > So if you have branches with changes, follow Daniel's instructions. If
> you
> > don't, you can still use the -s ours strategy to "switch" from one branch
> > to
> > another.
> >
> > Until Apache comes with a better solution, I'm going to keep my
> > repository synchronized against
> > https://svn.eu.apache.org/repos/asf/buildr.
> > I suggest you all do the same, that way we have the same history and can
> > easily merge with each other.
> >
> > Assaf
> >
> > [1] http://jukka.zitting.name/git/
> >
> >
> >
> > >
> > >
> > > Daniel
> > >
> >
>
Re: Welcome to Rebase Hell!
Posted by Daniel Spiewak <dj...@gmail.com>.
Actually, I don't think that it is a restriction that Apache has placed on
their SVN server (AFAIK). The way that git-svn works is it grabs every
single change set back to the beginning of time. This means a really, *
really* huge checkout from the server, all at once. While this is not
strictly a problem for SVN, it does pose some issues when SVN is being run
through mod_dav. Basically, mod_svn_dav (or mod_svn, whichever it is) keeps
accruing objects in memory as the checkout progresses. At some point, the
process handling your HTTP request actually crashes because it runs out of
heap space.
I ran into this issue at my previous job, though it would manifest itself as
a PROPSET error on svn checkout. Because we had one particularly huge
changeset, I was never able to do a full checkout of all revisions from
scratch. Using the svn client, things were at least passable (since you
could repeatedly "svn up"), but it wasn't pretty. The really depressing
thing is that this is a known issue. The mod_dav folks say that it's SVN's
fault, while the SVN folks keep bouncing the problem back. I've also heard
it said that no one would ever run into this issue when using SVN
"properly", so it's not a serious concern. :-S The officially "workaround"
is to just allocate more memory to httpd.
I'm not sure why this wouldn't affect incubator, but it may be partially due
to the fact that you performed your initial clone of the Buildr repo at a
much earlier point than this. Alternatively, there may be some other
factors in play here beyond annoying bugs associated with SVN+HTTPS.
Daniel
On Sun, Mar 1, 2009 at 12:40 AM, Assaf Arkin <ar...@intalio.com> wrote:
> On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <dj...@gmail.com>
> wrote:
>
> > Those of you following development progress using Git are probably
> starting
> > to notice that the classical "Vic Master" is no longer the all-knowing
> > source of data. Actually, Assaf's GitHub fork has become the more
> > trustworthy one. This is because upon its exit from incubation, Buildr
> > gets
> > to move its SVN repository to a new URL. This is good for the project,
> but
> > bad for the Git forks since git-svn stores the URL information in its
> > commit
> > messages.
> >
> > The solution of course is to re-clone from SVN, which I assume exactly
> what
> > Assaf did. There result is a repository which contains all of the same
> SVN
> > commits as Vic's, but different messages and very different SHA1
> revisions,
> > meaning that Git has a much harder time merging between the two. I
> > discovered this when I attempted to merge Assaf's latest changes with my
> > master (forked from Vic's). 57 conflicts later (all petty, little issues
> > unrelated to my additions), I finally had a working master with the
> latest
> > commits. Unfortunately, when I cloned Assaf's repository directly and
> > attempted to merge back some of my changes, it became very apparent that
> I
> > would need to fix the issue in a more scientific manner.
> >
> > Long story short, the solution is to rebase all of your branches onto
> > Assaf's master. I did this by finding the exact commit where I diverged
> > from vic (I had it tagged, actually) as well as the corresponding commit
> in
> > Assaf's master. These commits I tagged "branch-point" and
> > "new-branch-point", respectively. Then for each branch, I did something
> > like the following:
> >
> > git checkout scala-joint-compilation
> > git rebase new-branch-point
> >
> > Once this was done, I went back to my master and performed a similar
> > procedure:
> >
> > git checkout master
> > git rebase -s ours new-branch-point
> >
> > This effectively wiped out all of my changes in that branch (it's
> possible
> > that some commits may remain if you try it, but none did in my case).
> Once
> > this was done, I went and picked through my origin/master log to see what
> I
> > was missing. This meant re-merging all of my branches:
> >
> > git merge scala-joint-compilation
> > git merge clojure
> > ...
> >
> > Also, I had to cherry-pick a few commits that I had done on master (like
> > four or five):
> >
> > git cherry-pick all-your-ant-base
> > ...
> >
> > Once this was done, I pushed the result back to GitHub:
> >
> > git push -f origin
> >
> > The one caveat to this approach is I had all of my changes on numerous
> > separate branches (for patching reasons). All of these branches were
> > branched off of the same point on vic/master. Since there hadn't been
> any
> > merging *between* the branches (only onto master), it was fairly easy to
> > just rebase these branches onto the new trunk (I only had three conflicts
> > in
> > the whole process, all easily resolved). Just judging by GitHub, not
> many
> > people are managing their repositories in this fashion. However, this
> does
> > mean that you could be able to just rebase without the "-s ours" on your
> > master and come to the same result.
> >
> > The point is that you will need to perform some conniptions of this sort
> in
> > order to fix your repositories, otherwise your changes will remain
> > incompatible with the Buildr mainline trunk: you won't be able to
> (easily)
> > merge assaf/master, and he won't be able to (easily) pull from you.
> >
> > Incidentally, if anyone has a *better* way of doing this (particularly
> one
> > where the entire master history doesn't get wiped out), I'm all ears! I
> do
> > still have the unmerged repository sitting in Time Machine, so I'm
> > perfectly
> > willing to roll-forward a copy and try again if the result turns out to
> be
> > more correct.
>
>
> Thanks.
>
>
> AFAIK it's not possible to git svn clone directly from svn.apache.org due
> to
> some weird restriction they placed on the SVN server, it will just keep
> git-svn hanging forever. Somehow that doesn't affect incubator projects, or
> svn.eu.apache.org, although my starting point was Jukka's unofficial but
> somewhat official git mirror[1].
>
>
> When you git log, check the git-svn-id:
>
> commit a3ab30a66a092bf730950bd95a1394253ebd2f39
>
> Author: Assaf Arkin <as...@apache.org>
>
> Date: Fri Feb 27 22:24:50 2009 +0000
>
>
> > Fixed RDoc 2.3/2.4 conflict on rake setup.
>
>
>
> git-svn-id:
>
> https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68
>
>
> If two repositories use a different URL -- look for http vs https,
> svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr --
> Git considers them distinct trees (branches). Any time you merge, Git will
> have to merge the entire history of these two branches, leading to a lot of
> conflicts.
>
> So if you have branches with changes, follow Daniel's instructions. If you
> don't, you can still use the -s ours strategy to "switch" from one branch
> to
> another.
>
> Until Apache comes with a better solution, I'm going to keep my
> repository synchronized against
> https://svn.eu.apache.org/repos/asf/buildr.
> I suggest you all do the same, that way we have the same history and can
> easily merge with each other.
>
> Assaf
>
> [1] http://jukka.zitting.name/git/
>
>
>
> >
> >
> > Daniel
> >
>
Re: Welcome to Rebase Hell!
Posted by Assaf Arkin <ar...@intalio.com>.
On Sat, Feb 28, 2009 at 8:52 PM, Daniel Spiewak <dj...@gmail.com> wrote:
> Those of you following development progress using Git are probably starting
> to notice that the classical "Vic Master" is no longer the all-knowing
> source of data. Actually, Assaf's GitHub fork has become the more
> trustworthy one. This is because upon its exit from incubation, Buildr
> gets
> to move its SVN repository to a new URL. This is good for the project, but
> bad for the Git forks since git-svn stores the URL information in its
> commit
> messages.
>
> The solution of course is to re-clone from SVN, which I assume exactly what
> Assaf did. There result is a repository which contains all of the same SVN
> commits as Vic's, but different messages and very different SHA1 revisions,
> meaning that Git has a much harder time merging between the two. I
> discovered this when I attempted to merge Assaf's latest changes with my
> master (forked from Vic's). 57 conflicts later (all petty, little issues
> unrelated to my additions), I finally had a working master with the latest
> commits. Unfortunately, when I cloned Assaf's repository directly and
> attempted to merge back some of my changes, it became very apparent that I
> would need to fix the issue in a more scientific manner.
>
> Long story short, the solution is to rebase all of your branches onto
> Assaf's master. I did this by finding the exact commit where I diverged
> from vic (I had it tagged, actually) as well as the corresponding commit in
> Assaf's master. These commits I tagged "branch-point" and
> "new-branch-point", respectively. Then for each branch, I did something
> like the following:
>
> git checkout scala-joint-compilation
> git rebase new-branch-point
>
> Once this was done, I went back to my master and performed a similar
> procedure:
>
> git checkout master
> git rebase -s ours new-branch-point
>
> This effectively wiped out all of my changes in that branch (it's possible
> that some commits may remain if you try it, but none did in my case). Once
> this was done, I went and picked through my origin/master log to see what I
> was missing. This meant re-merging all of my branches:
>
> git merge scala-joint-compilation
> git merge clojure
> ...
>
> Also, I had to cherry-pick a few commits that I had done on master (like
> four or five):
>
> git cherry-pick all-your-ant-base
> ...
>
> Once this was done, I pushed the result back to GitHub:
>
> git push -f origin
>
> The one caveat to this approach is I had all of my changes on numerous
> separate branches (for patching reasons). All of these branches were
> branched off of the same point on vic/master. Since there hadn't been any
> merging *between* the branches (only onto master), it was fairly easy to
> just rebase these branches onto the new trunk (I only had three conflicts
> in
> the whole process, all easily resolved). Just judging by GitHub, not many
> people are managing their repositories in this fashion. However, this does
> mean that you could be able to just rebase without the "-s ours" on your
> master and come to the same result.
>
> The point is that you will need to perform some conniptions of this sort in
> order to fix your repositories, otherwise your changes will remain
> incompatible with the Buildr mainline trunk: you won't be able to (easily)
> merge assaf/master, and he won't be able to (easily) pull from you.
>
> Incidentally, if anyone has a *better* way of doing this (particularly one
> where the entire master history doesn't get wiped out), I'm all ears! I do
> still have the unmerged repository sitting in Time Machine, so I'm
> perfectly
> willing to roll-forward a copy and try again if the result turns out to be
> more correct.
Thanks.
AFAIK it's not possible to git svn clone directly from svn.apache.org due to
some weird restriction they placed on the SVN server, it will just keep
git-svn hanging forever. Somehow that doesn't affect incubator projects, or
svn.eu.apache.org, although my starting point was Jukka's unofficial but
somewhat official git mirror[1].
When you git log, check the git-svn-id:
commit a3ab30a66a092bf730950bd95a1394253ebd2f39
Author: Assaf Arkin <as...@apache.org>
Date: Fri Feb 27 22:24:50 2009 +0000
> Fixed RDoc 2.3/2.4 conflict on rake setup.
git-svn-id:
https://svn.eu.apache.org/repos/asf/buildr/trunk@74872213f79535-47bb-0310-9956-ffa450edef68
If two repositories use a different URL -- look for http vs https,
svn.eu.apache.org vs svn.apache.org, asf/buildr vs asf/incubator/buildr --
Git considers them distinct trees (branches). Any time you merge, Git will
have to merge the entire history of these two branches, leading to a lot of
conflicts.
So if you have branches with changes, follow Daniel's instructions. If you
don't, you can still use the -s ours strategy to "switch" from one branch to
another.
Until Apache comes with a better solution, I'm going to keep my
repository synchronized against https://svn.eu.apache.org/repos/asf/buildr.
I suggest you all do the same, that way we have the same history and can
easily merge with each other.
Assaf
[1] http://jukka.zitting.name/git/
>
>
> Daniel
>