search for: zippered

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 of your branches' histories too it's > more involved, but I'm not s...

...t; that. In any case, even if someone does want that the nature of > > the zipper approach means it could be done later > > non-destructively. > > That's true, but then they would suffer the same duplication of > history that motivated you to create the zippered repository in > the first place. > > It isn't clear to me why it would suffer from the same duplication of > history? > The duplication of history is only due to the *rewrite* of the git > hash between the individual repo and the monorepo. > If we were starting with a s...

...o this with the results of that? >> >> On Thu, Nov 15, 2018 at 2:55 PM James Y Knight via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> 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...

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 with this p...

...9;d like to at least let him get back to this with the results of that? > >> On Thu, Nov 15, 2018 at 2:55 PM James Y Knight via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> 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: >>> &gt...

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

...in - I suspect others are hitting the same issues > as I in trying 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 go...

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

...;git replace"). Start with the git merge you already created (merging all your split-repositories into one branch on top of a monorepo-prototype commit). Then, "git replace" the monorepo-prototype commit that you merged in with a commit that has the same content, but from your "zippered" repository history. That won't change the hash (thus, future merging will work properly), but it effectively changes the history to be the way you'd like to see it. Thus you'll see the zipped history up until that point, avoiding seeing multiple copies of svn commits in your hist...

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.

...them into a combined view after each commit. > > While I personally don't see a problem with (1), I've heard people claim > that they want to use the monorepo to bisect arbitrarily far back into > history. If this is the case, we'd prefer an approach like (2). > > A zippered repository gives us a lot of the benefits of the prototype, > without a lot of the issues that are caused by rewriting history: > > - The commits from the official git mirrors exist as they are now, and > we don't need to deal with changing hashes. > > - Out-of-tree branc...

...t;>> >>> While I personally don't see a problem with (1), I've heard people claim >>> that they want to use the monorepo to bisect arbitrarily far back into >>> history. If this is the case, we'd prefer an approach like (2). >>> >>> A zippered repository gives us a lot of the benefits of the prototype, >>> without a lot of the issues that are caused by rewriting history: >>> >>> - The commits from the official git mirrors exist as they are now, and >>> we don't need to deal with changing hashes....

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

...kin" <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 back. if/when I find it I'll add it to the page. Josh ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs

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