Could you provide any examples of how the current model does not provide enough encouragement for innovation? What inherent properties of it make it so? How is it hurting the project right now?
-Krzysztof
Owen, and many others …
I do not wish to belabor this conversation as it distracts from everything else you all have to do.
The fact that llvm does have a synchronized repository on github is sufficient for me. I can fork it, hack on it, and keep it up to date as needed. If a change I make is sufficiently useful, I’ll just submit a patch.
The arguments about monotonically increasing revision number are, in my view, rather silly. That is not a very good reason for choosing or even staying with an SCM. There are stronger arguments for sticking with SVN.
The arguments about having a single line of change is valid, but SVN isn’t the only tool that supports that model. I’m in support of this approach as I use it on all my projects, including those using GIT.
I do understand that many automated processes are now built up around SVN and changing to git would be a huge effort with little to be gained.
In putting out my inquiry, I was concerned more about LLVM being sequestered off in a corner of the Internet and not having its code as easily available as on, say, github. Code access and brows ability is one of the things that fosters innovation. However, I get that switching would be a huge pain and that LLVM is by now a mature project where perhaps innovation is taking a back seat to maintaining a standard development model that its many existing developers have grown accustomed to.
So, let’s follow Owen’s suggestion and end the conversation about SCM choice and replace it with conversations about improving the development process. I for one will need to get back into that process before I can comment because it is clear that after 7 years, things just ain’t the same. 
Best,
Reid.
Reid Spencer wrote:
>> Convert to GIT
> I am surprised noone has mentioned the one of the biggest
> advantages of Git which is proper author attribution for
> non-core and drive-by patch contributors.
+1
And this is where svn does not scale. The only way I know to do it with
SVN is to add write access to the real contributor (Hey Chris! Can you
give me write accesses to the LLVM-related repository???) or to use
privileged access to the repository to do a
svn propset svn:author ...
but I do not remember the details, since I am no longer a serious svn
user for almost a decade.
But in the last case, that means rewriting history from the point of
view of the git-svn gateway in use and you can imagine the havoc going
this way... 
> As for all the reason why the LLVM project does not use Git, I
> wonder why large complex projects like the Linux kernel, Wine,
> MinGW-w64, GHC and many many others don't seem to have any
> major problems using Git.
Because these projects *chose* to use git.
Of course the Linux case is special since git was designed as *the* tool
to host Linux development...
Owen, and many others …
I do not wish to belabor this conversation as it distracts from everything
else you all have to do.The fact that llvm does have a synchronized repository on github is
sufficient for me. I can fork it, hack on it, and keep it up to date as
needed. If a change I make is sufficiently useful, I’ll just submit a
patch.The arguments about monotonically increasing revision number are, in my
view, rather silly. That is not a very good reason for choosing or even
staying with an SCM. There are stronger arguments for sticking with SVN.The arguments about having a single line of change is valid, but SVN isn’t
the only tool that supports that model. I’m in support of this approach as
I use it on all my projects, including those using GIT.I do understand that many automated processes are now built up around SVN
and changing to git would be a huge effort with little to be gained.In putting out my inquiry, I was concerned more about LLVM being
sequestered off in a corner of the Internet and not having its code as
easily available as on, say, github. Code access and brows ability is one
of the things that fosters innovation. However, I get that switching would
be a huge pain and that LLVM is by now a mature project where perhaps
innovation is taking a back seat to maintaining a standard development
model that its many existing developers have grown accustomed to.So, let’s follow Owen’s suggestion and end the conversation about SCM
choice and replace it with conversations about improving the development
process. I for one will need to get back into that process before I can
comment because it is clear that after 7 years, things just ain’t the same.
There is definitely quite a bit of stuff that is recognized as being pretty
crusty and in need of revitalization (and for all I know, you might find
familiar even with 7 years of absence). Bugpoint, TableGen, the llvm.org
website, bugzilla, etc.
-- Sean Silva
Even though git could be used in the same way as svn, why migrate just to
re-create the current workflow? Doesn't make too much sense to me. A
migration to git would have to include some other benefit, not just be
change for the sake of it.
I think our routine workflow suffers quite a bit from the svn
emphasis. Sending text patches is all very well from a portability
point, but it makes applying someone else's commits rather annoying
(particularly for commit, but even for testing):
1. Download the patch.
2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends
on exactly what program downloaded it) and what the name of the file
was.
3. Either look or randomly guess what -pN you need to apply it.
4. Check things.
5. Open the blasted file again to recover the commit message
(frequently weirdly indented because that's what "git show" produces).
Or make one up.
6. Commit with that via copy/paste.
7. Hope you didn't forget to "git/svn add" the new test before committing.
This is all you can do in svn (as far as I'm aware), but it's
something git has solutions for. Some unified "git fetch" available
for this would be very useful for example, even if we do decide a
world without monotonic numbers is too scary for us.
Tim.
Most of this is solved by importing the patch with git am. But it works only if the patch was generated from git format-patch.
If you want to save also the “download and find the patch file”, any review coming from Phabricator can be committed in a single command, for example:
$ arc patch D7003
Mehdi
Once you enforce a linear master branch by requiring only “git merge --no-ff”, it’s easy enough for a commit hook to add a monotonic tag to each commit. They’re very lightweight.
Yes, someone needs to write the five lines of code to do that, but that’s what you get when you use a SCM construction kit instead of a one-size-fits-all solution.
Incidentally, about splitting submodules out. NOOOOOOOOOO!
I checked out out the all in one https://github.com/chapuni/llvm-project.git repository. It took 2 minutes (to New Zealand) and the resulting .git directory is 581 MB. For the entire history of everything! That’s utterly trivial. Less than a dollar worth of fast SSD, or maybe three cents of spinning rust.
Why would you want to split that up and lose atomic commits and bisect across different parts?
Most of this is solved by importing the patch with git am. But it works only if the patch was generated from git format-patch.
Trouble is, that's not what we get, or at least nowhere near often
enough to even bother learning that tool.
If you want to save also the “download and find the patch file”, any review coming from Phabricator can be committed in a single command, for example:
$ arc patch D7003
Yeah, I'm not installing PHP locally just for a non-standard arc tool.
I'm quite happy with what Phabricator does on the web, but it should
present standard interfaces for clients (like a git branch/tag).
Tim.
Most of this is solved by importing the patch with git am. But it works only if the patch was generated from git format-patch.
Trouble is, that's not what we get, or at least nowhere near often
enough to even bother learning that tool.
Well, if someone send a patch using “git show” instead of “git format-patch”, just ask to resend ?
And the learning curve is … almost inexistant, there is nothing to learn. “git am path_to_the_patch” and you are done.
You can even solve the download part by running "git am” and copy-pasting the content of the diff
If you want to save also the “download and find the patch file”, any review coming from Phabricator can be committed in a single command, for example:
$ arc patch D7003
Yeah, I'm not installing PHP locally
It seems someone did it for you "PHP has come standard with Macs since OS X version 10.0.0"
just for a non-standard arc tool.
I am not sure how to determined what is or is not a standard tool...
I'm quite happy with what Phabricator does on the web, but it should
present standard interfaces for clients (like a git branch/tag).
That would be nice indeed.
(other asked for it ⚓ T127 Find way to use Differential with plain git (i.e.: without requiring arc) )
I think we should just get some tiny python script that replaces the *tiny*
amount of logic we actually need from 'arc'. =]
Well, if someone send a patch using “git show” instead of “git format-patch”, just ask to resend ?
And if they're using svn? Or arc (I don't actually care what it does though)?
It seems someone did it for you "PHP has come standard with Macs since OS X version 10.0.0"
I only use OS X at work, where I'd have to get arc from source. Again,
I simply don't think whatever web interface we (sometimes) use should
be dictating our command-line tools.
I am not sure how to determined what is or is not a standard tool...
arc is non-standard. It uses PHP; it's not even in MacPorts for when I
am at work. I would vigorously oppose any recommendation to use its
command-line tool as standard LLVM practice.
As I said, I'm fine with that crap happening on a web-server someone
else has to administer. I'm not fine with having to deal with it
myself.
Tim.
> Even though git could be used in the same way as svn, why migrate just to
> re-create the current workflow? Doesn't make too much sense to me. A
> migration to git would have to include some other benefit, not just be
> change for the sake of it.I think our routine workflow suffers quite a bit from the svn
emphasis. Sending text patches is all very well from a portability
point, but it makes applying someone else's commits rather annoying
(particularly for commit, but even for testing):1. Download the patch.
2. Remember where you put it (~/Downloads, ~, ~/Documents -- depends
on exactly what program downloaded it) and what the name of the file
was.
3. Either look or randomly guess what -pN you need to apply it.
4. Check things.
5. Open the blasted file again to recover the commit message
(frequently weirdly indented because that's what "git show" produces).
Or make one up.
6. Commit with that via copy/paste.
7. Hope you didn't forget to "git/svn add" the new test before committing.This is all you can do in svn (as far as I'm aware), but it's
something git has solutions for. Some unified "git fetch" available
for this would be very useful for example, even if we do decide a
world without monotonic numbers is too scary for us.
Personally one of the things I really like about LLVM is precisely this
"human" aspect of applying patches from the mailing list for people without
commit access. It adds some extra human redundancy around all-important
new-contributor patches where almost by definition you will need to provide
some human feedback to the contributor in order to help their next patch be
better (and determining what feedback to give and cogently formulating it
is much more work than copypasting some stuff or guessing a -pN).
Having patch application fully automated only matters IMO if this this form
of patch application is the primary way work gets integrated into the
mainline; but that is not the case, since the primary way work gets
committed on the mainline in the LLVM project is by trusted contributors
with post-commit review (compare to e.g. Linux where patch application *is*
the primary way that work gets integrated into the mainline, so it makes
sense to have the process highly automated).
-- Sean Silva
I'm generally trying to stay out of this thread, because I disagree with pretty much everything Reed wrote (and think that proposing a major change to the development model is a funny thing to do when you haven't been an active contributor for years).
That said, I'd like to point out that the mean time between someone sending me a request for commit access (along with the correct password hash) and them being granted commit access is around 1-3 hours. If someone has observed a practical problem I'd love to hear about it.
-Chris