llvm dev - Feb 2011 - [LLVMdev] Official git mirroring of llvm, clang, lldb, test-suite, etc.?

Óscar Fuentes <ofv at 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.  :)
>> 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

On 2011-02-01 19:40, David A. Greene wrote:
> 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.
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 at gmail.com> writes:
> On 2011-02-01 19:40, David A. Greene wrote:
>> 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.
>
> 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.
SVK is a band-aid at best.  Again, it can't be used to connect two
distinct repositories, AFAIK.

An official LLVM git mirror that's updated every time there is a commit
to svn would help a lot.

                                 -Dave