search for: zippering

Justin Bogner <mail at justinbogner.com> writes: > I'll write up some more detailed docs on this, but all you need to do is > a subtree merge to one of the zippered commits. This will then prevent git-biisect from working properly, unfortunately. Maybe most people don't need it be we should be aware of and communicate the tradeoffs. > If you want a monorepo view for all

Mehdi AMINI <joker.eph at gmail.com> writes: > > If you want a monorepo view for all of your branches' histories > > too it's more involved, but I'm not sure anyone really needs > > that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. >

I don't feel like I can unilaterally declare this topic closed, since there was an objection to that last time. But with no additional feedback after another week, I'd still really like to close this out, and start moving forward with the original plan, again... On Mon, Nov 26, 2018 at 2:28 PM James Y Knight <jyknight at google.com> wrote: > It's been a week and a half more

Based on the feedback so far, I propose that we call this discussion done -- we will not go with this zippered proposal, but will proceed with https://github.com/llvm-git-prototype/llvm/. On Thu, Nov 15, 2018 at 5:06 PM David Greene via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org> writes: > > > What is the status

Yes, I’m still trying to evaluate the migration script’s downsides as compared to the zipper approach’s downsides. Sorry that I got a little held up, but I have to balance evaluating this with getting other work done. I should have some feedback to a few of the responses on this thread next week. I really don’t think I can respond in a useful/productive way before I’ve finished these

Justin Bogner via llvm-dev <llvm-dev at lists.llvm.org> writes: > The layout here is not at all different, only the process by which the > repo is generated. I strongly believe that a history preserving > conversion is very important if we want to avoid making porting > out-of-tree work horribly disruptive. How would an out-of-tree branch be ported with this new approach? Do

...ying to integrate with this version of the monorepo. > What is the status with this proposal? It has been 2 weeks now since the initial email and it seems like the discussion is slowing down. Do we still want to consider this zippered approach as a possibility for the official repo? Is the zippering tool proposed here[1] sufficient for out-of-tree git users? I think it's important to make a decision on this soon. I know a year seems like a long time to migrate, but with the holiday season approaching in the US it's going to be down to 9 months before we know it. -Tom [1] http://lis...

On Fri, Nov 2, 2018 at 2:11 PM Justin Bogner <mail at justinbogner.com> wrote: > James Y Knight <jyknight at google.com> writes: > > Thanks for writing this up. I think it's a really important point which > > deserves discussion. > > > > Ultimately, I think it is a question as to whether to prioritize the easy > > switchover for existing out of

Thanks for writing this up. I think it's a really important point which deserves discussion. Ultimately, I think it is a question as to whether to prioritize the easy switchover for existing out of tree forks, or to prioritize having the best conversion we can make. I feel very strongly that the latter should be the priority for the official repository conversion, and that, therefore, we

In a Readhat 9 system, I have a simple php file "test.php" with the following content to generate Setup.exe: <?php echo exec("pwd"); exec('/usr/bin/wine rar a -a -c- -cfg- -k -m4 -zc:\\\\zipper\\\\Setup.cmt -sfx Setup.exe @c:\\\\zipper\\\\Setup.lst '); ?> When I run it as a CGI script via command line as "php test.php" . The .exe is

aotheoverlord wrote: > > > Maybe I missed it, but could you tell us which version of PowerBuilder you are using? PowerBuilder 7... I tried to compile the application in PowerBuilder 6, but it doesn't works.

Hi, Thanks for starting this discussion Justin! On 10/31/18 5:22 PM, Justin Bogner via llvm-dev wrote: > Hi all, > > I've spent some time in the last couple of days trying to figure out how > to adopt the [LLVM git monorepo prototype] for an out of tree backend. > TLDR: I'm not convinced that this prototype is the right approach to > converting to the monorepo, and I

I just want to point out that the issue of incompatible history is not new. This has been getting discussed all the way back in July 2016. http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html <http://lists.llvm.org/pipermail/llvm-dev/2016-July/102657.html> As James said in that email: > That we'll be getting incompatible history has been glossed over, and it is >

Mehdi AMINI <joker.eph at gmail.com> writes: > Yes, but that's the case for the zipper repo anyway: one merge per > commit. The point is that the second commit is just a trivial merge, > it wouldn't show up in a file `git log` for example. > In the linear rewritten monorepo, adding the history taken from the > existing git mirror would lead to duplicated commits, as

Full_Name: Henrik Bengtsson Version: R v1.7.0 OS: WinXP Pro Submission from: (NULL) (130.235.2.229) There seems to be an upper limit of the number of files (approx 1000 files) a zip-file can contain when unpacking it with zip.unpack(). This results in an R crash. This bug is urgent since install.packages() relies on zip.unpack() and too big packages/bundles won't install with the current R

--- "David W. Tamkin" <dattier@panix.com> wrote: > Three styles of T-shirts plus hooded sweatshirts, but no FLAC > jackets? seems like slam dunk doesn't it :) but for this run I'm trying to use the same screens on all items to keep the cost down, which rules out the logo on the front of a zippered jacket. still looking for a suitable one where logo can go on the

Hi all, I`m a newbie and I need any help!! I want to istall xilinx under win and after the command wine setup.exe Iget the following message: fixme:module:CreateProcessA (D:\ce\jre\1.2\bin\java.exe,...): HIGH_PRIORITY_CLASS ignored fixme:pthread_kill_other_threads_np FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock FIXME:pthread_rwlock_rdlock FIXME:pthread_rwlock_unlock

Full_Name: Henrik Bengtsson Version: R v1.7.0 OS: WinXP Pro Submission from: (NULL) (130.235.2.229) There seems to be an upper limit of the number of files (approx 1000 files) a zip-file can contain when unpacking it with zip.unpack(). This results in an R crash. This bug is urgent since install.packages() relies on zip.unpack() and too big packages/bundles won't install with the current R

Full_Name: Henrik Bengtsson Version: R v1.7.0 OS: WinXP Pro Submission from: (NULL) (130.235.2.229) There seems to be an upper limit of the number of files (approx 1000 files) a zip-file can contain when unpacking it with zip.unpack(). This results in an R crash. This bug is urgent since install.packages() relies on zip.unpack() and too big packages/bundles won't install with the current R

Well shoot, you beat me to it. :) I've been working on a similar tool but it's not ready yet. Looking forward to trying yours! -David James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> writes: > I'm about to post exactly this tool -- I've been testing it on the > CHERI forks of llvm/clang/lld (lots of history and merges and stuff