similar to: [LLVMdev] SVN/Git Mirror Hooks

How does the LLVM server keep the git svn mirror up to date? Are there hooks in the svn server that automatically update the git mirror? If so, are any of these tools public? I ask because I'm looking at setting up some mirrors at work and I may (I stress _may_) have a way to make git mirrors interact somewhat sanely with each other. But I need something that keeps a git mirror in sync

Hi David, > How does the LLVM server keep the git svn mirror up to date?  Are there > hooks in the svn server that automatically update the git mirror? Yes >  If so, are any of these tools public? It's just "git svn fetch" -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

On 15 Nov 2012, at 08:31, Greg Fitzgerald wrote: > Has there been discussion about having svn mirror git instead of vice versa? I've been happy with the git+cmake+ninja combo for a while now, but the online docs suggests this configuration is second-class to svn+autotools+make. Is the community transitioning to any particular configuration? I think svn works better than git as an

Eric Christopher <echristo at gmail.com> writes: > On Thu, Jun 19, 2014 at 11:52 AM, <dag at cray.com> wrote: > >> Is svn metadata missing from some of the upstream git mirrors? I really >> don't want to git-svn fetch if I can avoid it. > > I use it for clang and llvm. I haven't tried for the others. According to the web page, it should at least work

>> clock skew (which is easy to get in a VM) can confuse Ninja in a way >> that doesn't give helpful errors. > >This is a significant issue. I would not want to transition to >cmake+ninja before this is fixed. Do you mean in the same way that clock skew would affect Make? Or just that Ninja doesn't provide that nice "clock skew detected" message that Make

Hi everyone, I tried to clone the git mirrors and set up git-svn metadata according to these instructions: http://llvm.org/docs/GettingStarted.html#git-mirror Importantly, I did this (replacing <username>, of course): % git svn init https://llvm.org/svn/llvm-project/llvm/trunk --username=<username> % git config svn-remote.svn.fetch :refs/remotes/origin/master % git svn rebase -l #

Greg Fitzgerald <garious at gmail.com> writes: >> I've yet to see anyone propose this. Oh, many people have proposed using git's features. > Then I'll be the first.  :) > > The benefit is that the review process would require no file copies or > email attachments, shorter email conversations, no copying code during > reviews to simulate inline comments,

David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > clock skew (which is easy to get in a VM) can confuse Ninja in a way > that doesn't give helpful errors. This is a significant issue. I would not want to transition to cmake+ninja before this is fixed. -David

>> Most development is not "some contributor's fork". > > Well, in the git model every developer has a fork. > >> What you suggest works great for the occasional drive-by >> contributors, but most development is not from drive-by's. > > Not sure what you mean by "drive-by" but in git this is really > irrelevant, I think. Sorry for

Greg Fitzgerald <garious at gmail.com> writes: > In my humble opinion, there is a one biggest problem with git-svn and > svn. It requires the maintainer to rebase before committing, and in > git, this changes the the patch's unique ID. I didn't totally follow your argument so I'm sure I missed something. However, I don't think rebase is really the issue here.

This has been discussed many times. Might want to take a look in the mailing list archives. :) cmake and autotools are on roughly equal footing at this point with chandler and I handling each of them respectively and fairly quickly. git vs. svn is a different story though. -eric On Thu, Nov 15, 2012 at 8:31 AM, Greg Fitzgerald <garious at gmail.com> wrote: > Hi, > > Has there

On Thu, Nov 15, 2012 at 10:48 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: >> > I think svn works better than git as an authoritative upstream >> >> Would you mind expanding on this? What problem specifically is being solved? Linus and Guido both use DVCS's and the authoritative upstream is whatever URL the BDFL says it is. > > Monotonic version

> For example, say github's llvm-mirror was a contributor's fork. The review > process might look like this: > > Contributor: > Please review my patch: > https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 > > Maintainer: > Adds inline comments with online tool. Then when patch is looking good: > $ git fetch

Sean Silva <silvas at purdue.edu> writes: >> For example, say github's llvm-mirror was a contributor's fork. The review >> process might look like this: >> >> Contributor: >> Please review my patch: >> https://github.com/llvm-mirror/llvm/commit/4823be3be1d87632fbd51ce8e51a58ee5e44b115 >> >> Maintainer: >> Adds inline

On Fri, Nov 16, 2012 at 1:53 PM, Greg Fitzgerald <garious at gmail.com> wrote: > My interpretations, which later in this long email, I'll assume as > premises to a recommended action: > > * Chris finds code reviewers to be exceptionally rare and the > community's most valuable participants. My previous "spork" > suggestion would be a decision made my

> cmake and autotools are on roughly equal footing at this point with chandler > and I handling each of them respectively and fairly quickly. git vs. svn is > a different story though. Would you be willing to put this commitment to autotools in CODE_OWNERS.TXT? Sometimes I have needed to make changes to Makefiles and didn't know who was the right person to CC for it, so having an

David Chisnall <David.Chisnall at cl.cam.ac.uk> writes: > On 15 Nov 2012, at 12:31, <dag at cray.com> wrote: > >> - Easier third-party merging. Merging via git merge/rebase is MUCH >> simpler than merging a tarball from svn. I know the llvm leaders >> don't seem to care about this but it is a real issue for many users. >> >> - Ease of

On 15 Nov 2012, at 10:40, Greg Fitzgerald wrote: > Do you mean in the same way that clock skew would affect Make? Or just that Ninja doesn't provide that nice "clock skew detected" message that Make does? Or are you looking for a build system that uses file hashes instead of last-modified times? Ninja complains about circular dependencies when you have your clock set to the

Sean Silva <silvas at purdue.edu> writes: > The thing about this is that git-svn (un?)fortunately works so well > that you can get all of these benefits with the main repo still in > SVN. Hence, it is really a moot point regarding a switch to git for > the main repo. E.g.: I agree that git-svn is a big help but it is not the same as native git. For one thing, it can't

Hi, This probably isn't significant evidence about using svn as the authoritative revision control system for llvm but more just to point out that the svn users tend to consider that the only thing one would use revision control for is the mainstream development history tracking. I'll note that I during working ("development" but also bug-fixing and experimentation) since the