Official git mirroring of llvm, clang, lldb, test-suite, etc.?

I know this comes up periodically, but it looks like it has been a few months since there was any posting indicating that having an official git mirror for LLVM, et al. was still in the works.

I am wondering if there is a timeline or resources lined up to do this mirroring.

The distributed nature of git fits very well with any open source development, and it would be great if there were some support for a “pull request” model for submitting changes like the one implemented on github. Perhaps this is asking too much.

Thanks,

Mark

I know this comes up periodically, but it looks like it has been a few months since there was any posting indicating that having an official git mirror for LLVM, et al. was still in the works.

I am wondering if there is a timeline or resources lined up to do this mirroring.

The distributed nature of git fits very well with any open source development, and it would be great if there were some support for a "pull request" model for submitting changes like the one implemented on github. Perhaps this is asking too much.

What about using git-svn ?

Thanks,

Mark

-- Jean-Daniel

Jean-Daniel Dupas <devlists@shadowlab.org> writes:

greened@obbligato.org (David A. Greene) writes:

Jean-Daniel Dupas <devlists@shadowlab.org> writes:

I know this comes up periodically, but it looks like it has been a
few months since there was any posting indicating that having an
official git mirror for LLVM, et al. was still in the works.

What about using git-svn ?

git-svn often doesn't work, especially if the other side also needs
git-svn.

The git mirror would be read-only, so if you want to contribute changes
to LLVM using git you need git-svn anyways.

Óscar Fuentes <ofv@wanadoo.es> writes:

git-svn often doesn't work, especially if the other side also needs
git-svn.

The git mirror would be read-only, so if you want to contribute changes
to LLVM using git you need git-svn anyways.

I pull down changes from upstream much more frequently than I send
changes up. To send changes up, diff+patch+svn, while not ideal, is
workable.

                                 -Dave

greened@obbligato.org (David A. Greene) writes:

git-svn often doesn't work, especially if the other side also needs
git-svn.

The git mirror would be read-only, so if you want to contribute changes
to LLVM using git you need git-svn anyways.

I pull down changes from upstream much more frequently than I send
changes up. To send changes up, diff+patch+svn, while not ideal, is
workable.

Are you saying that git-svn is slow at pulling changes? It is quite okay
in my experience, unless you pull once every other month. But I can't
relate that to your original assertion quoted above.

What I recall from previous discussions is that you are interested on
having local feature branches shared among your coworkers. That's doable
with git-svn with some constraints.

Óscar Fuentes <ofv@wanadoo.es> writes:

Are you saying that git-svn is slow at pulling changes? It is quite okay
in my experience, unless you pull once every other month. But I can't
relate that to your original assertion quoted above.

I can't use git-svn to pull because we use svn on our end. One can't do
this:

(Upstream) svn <--> git-svn <--> git <--> git-svn <--> svn (Downstream)

because the revisions in the two svn repositories don't have anything to
do with each other.

What I recall from previous discussions is that you are interested on
having local feature branches shared among your coworkers. That's doable
with git-svn with some constraints.

Actually, I am mostly interesed in git because it makes merging in
upstream code dead simple. Right now I've implemented a couple of
downright scary scripts to hack a ditributed SCM module on top of
Subversion. It's really about as far away from "fun" as one can get.

It would be even better if LLVM had a git mirror that could push changes
to svn as well but let's do things one step at a time. :slight_smile:

                          -Dave

greened@obbligato.org (David A. Greene) writes:

I can't use git-svn to pull because we use svn on our end. One can't do
this:

(Upstream) svn <--> git-svn <--> git <--> git-svn <--> svn (Downstream)

because the revisions in the two svn repositories don't have anything to
do with each other.

That's what you deserve, for using svn at your side :wink:

But if you want to transfer revisions from LLVM's svn to your svn repo,
maybe you can do that:

(Upstream) svn <--> git-svn <--> svn (Downstream)

You would use two git-svn branches on the git repo, one for each svn
repo, and merge revisions among the two. I'm not user if that's
possible, though. Another option is to use two git-svn repos:

(Upstream) svn <--> git-svn <--> git-svn <--> svn (Downstream)

Actually, I am mostly interesed in git because it makes merging in
upstream code dead simple. Right now I've implemented a couple of
downright scary scripts to hack a ditributed SCM module on top of
Subversion. It's really about as far away from "fun" as one can get.

It would be even better if LLVM had a git mirror that could push changes
to svn as well but let's do things one step at a time. :slight_smile:

The difficult part is not on LLVM's using svn, the problem is on you
using svn.

And for a git mirror that pushes changes to the LLVM svn repo, that's
*way* more tricky than it seems.

Óscar Fuentes <ofv@wanadoo.es> writes:

greened@obbligato.org (David A. Greene) writes:

I can't use git-svn to pull because we use svn on our end. One can't do
this:

(Upstream) svn <--> git-svn <--> git <--> git-svn <--> svn (Downstream)

because the revisions in the two svn repositories don't have anything to
do with each other.

But if you want to transfer revisions from LLVM's svn to your svn repo,
maybe you can do that:

(Upstream) svn <--> git-svn <--> svn (Downstream)

You would use two git-svn branches on the git repo, one for each svn
repo, and merge revisions among the two. I'm not user if that's
possible, though. Another option is to use two git-svn repos:

(Upstream) svn <--> git-svn <--> git-svn <--> svn (Downstream)

I asked about both to the git guys. They said it isn't supported.
Double-ended git-svn just won't work, period. You can't do it because a
git branch is still tied to the revision numbering of the first git-svn
gateway created. Git branches still must relate to each other, they
can't run independently or one wouldn't get any merging benefit.

It would be even better if LLVM had a git mirror that could push changes
to svn as well but let's do things one step at a time. :slight_smile:

The difficult part is not on LLVM's using svn, the problem is on you
using svn.

Umm...that's more than a bit off-putting, thanks. If it's a problem to
use svn (and it IS a problem), then it's a problem on BOTH ends. That
is in fact why people are asking about it. Remember, it ain't just me.
I didn't even bring up this current thread.

And to be clear, the root of the problem _is_ LLVM's using svn because
it doesn't allow the kind of distributed development natural to an open
source project. If one is not supposed to use svn (the official blessed
LLVM SCM) on "our side," pray tell, what _are_ we supposed to use?

And for a git mirror that pushes changes to the LLVM svn repo, that's
*way* more tricky than it seems.

I suspect for exactly the same reasons git-svn isn't tenable in general.
svn is just bad business all around.

                         -Dave

greened@obbligato.org (David A. Greene) writes:

(Upstream) svn <--> git-svn <--> git-svn <--> svn (Downstream)

I asked about both to the git guys. They said it isn't supported.
Double-ended git-svn just won't work, period. You can't do it because a
git branch is still tied to the revision numbering of the first git-svn
gateway created. Git branches still must relate to each other, they
can't run independently or one wouldn't get any merging benefit.

My point is that you can use two git repositories, each one tracking one
svn repo, and move revisions from one to another. I never tried it so
don't know how well it works. You may be right about the difficulty of
merging (you would be rebasing all the time, to be precise, but anyways
you are forced to rebase if you are using git-svn on one end.)

The difficult part is not on LLVM's using svn, the problem is on you
using svn.

Umm...that's more than a bit off-putting, thanks.

Sorry, thas was not my intention. There was an smiley somewhere around
there.

If it's a problem to
use svn (and it IS a problem), then it's a problem on BOTH ends.

I'll say that your svn is creating more trouble than LLVM's svn when you
are ready to send your changes upstream. After all, you are the
developers (working on "feature branches"), while LLVM's svn can be
considered the "master branch". This applies too in case you have a
private branch. As you say, git makes merging an easy task and keeping a
private branch is about merging all the time.

That is in fact why people are asking about it. Remember, it ain't
just me. I didn't even bring up this current thread.

And to be clear, the root of the problem _is_ LLVM's using svn because
it doesn't allow the kind of distributed development natural to an open
source project.

I agree that git has lots of advantages over svn, precisely for the type
of project LLVM is (not only open source, but with a focus on quality
and stability while the typical major feature requires lots of time,
careful programming, tests and reviews.)

If one is not supposed to use svn (the official blessed
LLVM SCM) on "our side," pray tell, what _are_ we supposed to use?

Because LLVM chose to use svn at some point on the past (when
distributed tools were not so mature and undestood as they are now) and
because there is no enough perception of the advantages associated with
a change, it is no excuse for you not doing what is most convenient for
your work.

Or do you think that convincing your managers about the change is more
difficult than convincing the LLVM admins? :wink:

[snip]

We could switch back to CVS...

-Chris

lol

Óscar Fuentes <ofv@wanadoo.es> writes:

I asked about both to the git guys. They said it isn't supported.
Double-ended git-svn just won't work, period. You can't do it because a
git branch is still tied to the revision numbering of the first git-svn
gateway created. Git branches still must relate to each other, they
can't run independently or one wouldn't get any merging benefit.

My point is that you can use two git repositories, each one tracking one
svn repo, and move revisions from one to another. I never tried it so

No, we can't. Git doesn't work that way. Git uses a set of
repositories all cloned fronth each other. One can't simply merge from
one arbitrary git repository to another.

The difficult part is not on LLVM's using svn, the problem is on you
using svn.

Umm...that's more than a bit off-putting, thanks.

Sorry, thas was not my intention. There was an smiley somewhere around
there.

No problem. e-mail is tough to get right. :slight_smile:

If it's a problem to
use svn (and it IS a problem), then it's a problem on BOTH ends.

I'll say that your svn is creating more trouble than LLVM's svn when you
are ready to send your changes upstream. After all, you are the
developers (working on "feature branches"), while LLVM's svn can be
considered the "master branch". This applies too in case you have a
private branch. As you say, git makes merging an easy task and keeping a
private branch is about merging all the time.

I certainly don't want to be using svn. Believe me, if I could dump svn
this afternoon, I absolutely would.

The problem with svn is there is no "master branch" in the sense of git.
One can't easily keep a private repository of LLVM because svn is by
nature centralized.

Because LLVM chose to use svn at some point on the past (when
distributed tools were not so mature and undestood as they are now) and
because there is no enough perception of the advantages associated with
a change, it is no excuse for you not doing what is most convenient for
your work.

Again, the problem is that there is no convenient solution. Everything
involves manual diff+patch at some point. This is entirely because svn
is not a distributed SCM.

The reasons for using svn in the past were entirely correct. But the
technology has advanced far beyond what it was back then. I am not
demanding any sort of change, just pointing out what the cost of the
current system is. An official git mirror would solve about half of the
current problems and that's probably good enough for most people.

                               -Dave

Garrison Venn <gvenn.cfe.dev@gmail.com> writes:

lol

LOL, yes, but svn is not much better than cvs. It makes doing release
branches slightly easier, but that's about it. svn in no way tackles
the real development prodcess.

                              -Dave

Please don't make posts like this to the list.

John.

FWIW I used "svk" for a little while, to be able to make local commits
on a SVN repository. It was certainly better than manually patching stuff.
I think I used it only for a few months though, before switching to
'git' though.

Best regards,
--Edwin

Török Edwin <edwintorok@gmail.com> writes: