similar to: Alioth Subversion repository freeze

There is now a public reposurgeon repository at: git at gitorious.org:reposurgeon/reposurgeon.git I've tagged 2.0pre9 there, for two purposes: * Charles can verify that I've solved the missing-files problem. * Hartmut can rework the few of his patches I didn't merge into reposurgeon. Charles, our next and final challenge is to generate proper merge commits in the NUT repo

Hi Eric, One corner case I ran across when building from a reposurgeon-generated tree is that .gitignore files do not seem to be generated when a directory is created at the same time as its svn:ignore property is set. In NUT, this manifests itself in r3109: http://trac.networkupstools.org/projects/nut/changeset/3109 Trac doesn't show it there, but scripts/avahi was created in that commit,

I have created a git repository for the three metadata files used in the NUT-UPS conversion. The purpose of this is to allow Charles to edit the lift script. The repository is at git at gitorious.org:reposurgeon/nut-conversion.git This supplements the reposurgeon 2.0pre repository at git at gitorious.org:reposurgeon/reposurgeon.git Here is the current state of play: 1. reposurgeon is

Who knew my core algorithm for associating copy operations with base commits could turn out to be wrong at this late date? Well, not so much "wrong" perhaps, but incomplete. The apparmor branch presented a case I'd never seen before. Explanation in the log comment. The conversion metadata repository continues to be at git at gitorious.org:reposurgeon/nut-conversion.git This

I've pushed 2.10pre to git at gitorious.org:reposurgeon/reposurgeon.git and there's a new version of the conversion metadata at git at gitorious.org:reposurgeon/nut-conversion.git I'm not entirely happy with the branch link deduction, but I think this is the best we're going to do without manual intervention to break some harmless but spurious parent links. The

On Nov 13, 2012, at 3:37 PM, Arnaud Quette wrote: > Fix Buildbot failures on commit r3776 One small request in the commit messages: please mention exact commit numbers only if the commit is hard to find. Something like "fix buildbot failures from previous commit" is specific enough, without making the reader look up a specific commit number. The reason is that it will be harder to

This is a consolidated reply to your four most recent emails. > I am trying to leverage reposurgeon to automate the process of finding merge > points, and I seem to be spinning my wheels. Can you provide an example of how > you are searching for merges? Not a working one, yet. That code is buggy. It's my next thing to work on. >reposurgeon% merge (apcsmart-dev)

(Copied to Dave Hart at the NTP project, who's interested in the code's progress for non-NUTty reasons. Dave, the background is that I'm doing a trial conversion of the Network UPS Tools repo.) First, repostreamer per se is dead. As it evolved it kept pulling in more bits of code from reposurgeon until I said "screw it!" and merged the repostreamer logic in as a reposurgeon

I've solved the detached-branch problem! It wasn't actually the branch-rename overwrites that were doing this - turns out I was trying to remove cvs2svn-generated junk commits too soon and in the process deleting critical branch links. I've uploaded a new tarball to http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz with the 2.0-pre3 version of reposurgeon in it. That

Hi. I have few different gitorious' accounts (for different workplaces and my personal), like git at gitorious.org:foo/foo.git git at gitorious.org:bar/bar.git I want to configure ssh to use different ssh keys for different repos. I try to do it with ~/.ssh/config. How I can match path? I want to get something like this: Match path foo/foo.git HostName gitorious.org User git

On 07/19/2010 05:14, Olivier Meurant wrote: > Together with Jan Sjodin (in copy of this email), we begin an > implementation of the JIT with MC. The idea, suggested by Jan, is to > develop a MCJIT in parallel of the current JIT and to keep the two > implementations until (at least) the new MC one is mature enough. > Currently code is kept on gitorious >

rdiscount-1.3.1.1 is uninstallable on solaris --------------------------------------------------------- root@dcb0:/opt/gitorious# gem install rdiscount -v 1.3.1.1 Building native extensions. This could take a while... ERROR: Error installing rdiscount: ERROR: Failed to build gem native extension. /opt/ruby/bin/ruby extconf.rb checking for random()... yes checking for srandom()... yes

I''m working on StrokeDB* right now and put pieces of networking stuff into a separate repository "Eventmachine utils". There are 3 useful libs already: protocol chaining, messaging protocol and marshalled messaging protocol. Check them out :-) Overview: http://gitorious.org/projects/eventmachine-utils Files:

Hi, I am getting this error when i execute rake db:create:all /opt/gitorious/vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:569: [BUG] unknown type 0x22 (0xc given) any clues ? -Manish -- Posted via http://www.ruby-forum.com/.

Ok, here is the first try to turn the gfxboot wrapper into a com32 module. I had to extend the interface to the gfxboot core a bit to get it working. So it works only with latest gfxboot from git://gitorious.org/gfxboot/gfxboot.git Steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: gfxboot_c32.diff.gz Type: application/x-gzip Size: 7220 bytes Desc: URL:

Together with Jan Sjodin (in copy of this email), we begin an implementation of the JIT with MC. The idea, suggested by Jan, is to develop a MCJIT in parallel of the current JIT and to keep the two implementations until (at least) the new MC one is mature enough. Currently code is kept on gitorious (http://gitorious.org/llvm-mc-jit/llvm-mc-jit). Following this, a boolean "bool MCJIT =

On Jun 24, 2011, at 12:44 PM, Yuri wrote: > On 07/19/2010 05:14, Olivier Meurant wrote: >> Together with Jan Sjodin (in copy of this email), we begin an >> implementation of the JIT with MC. The idea, suggested by Jan, is to >> develop a MCJIT in parallel of the current JIT and to keep the two >> implementations until (at least) the new MC one is mature enough. >>

Well, that wasn't as nasty as I feared it would be. Turns out that in the general case it's possible to partition a mixed-branch revision into branch cliques and generate multiple import-stream commits, one for each affected branch. We lose only if the split commit is the source of a later directory copy; I have a check for that that says, basically, "if you see this fatal error,

Op 20-09-2007 om 08:31 schreef St?phane ARQUER: > "previous" > > [ 'elf.c32' booting a RTEMS ELF binary ] > > - P4 2GHz 512M with a 3c905c PXE v2.20 > PXELINUX doesn't work with this one > > - P4 3GHz 2048M with an Intel 82573L gigabit eth PXE > PXELINUX works on this machine > > - HP kayak P3 866MHz with PXE v2.20 > PXELINUX doesn't

This is taking longer than I expected, because there is all kinds of cvs2svn-generated ugliness in your back history that tends to crash my tools. Your repo makes a great test case. (Yes, I know, that's like having someone say "Your dog is fantastically ugly!") Current state of things is that I have scrapped my precious approach, which was to put the Subversion tools in a Python