similar to: Public reposurgeon repo

Displaying 20 results from an estimated 1100 matches similar to: "Public reposurgeon repo"

2012 Apr 13
2
reposurgeon and svn:ignore on a newly added directory
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,
2013 Feb 06
1
Alioth Subversion repository freeze
Dear developers, thanks to Charles (Lepple) and ESR hard work, we are now able to finalize our migration from Subversion to Git, on Alioth. As of now, our Subversion repository on Alioth<https://alioth.debian.org/scm/?group_id=30602>is FROZEN! Any new svn commit may simply be discarded, so beware! Most active developers are currently using github, as a temporary mean. But if you have any
2012 Jan 09
1
reposurgeon progress
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)
2012 Nov 15
1
referring to earlier SVN commits
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
2012 Jan 18
0
Temporary git repo for the conversion metadata
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
2011 Dec 05
1
Progress report on git conversion
(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
2011 Dec 31
1
I've solved the detached-branch problem
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
2012 Jan 22
0
Fixing the misrooted branch
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
2012 Jan 19
1
git conversion progress
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
2011 Dec 09
1
[nut-commits] svn commit r3344 - branches/nut-scanner_dlopen
On Fri, 2011-12-09 at 03:46 +0000, Charles Lepple wrote: > Author: clepple-guest > Date: Fri Dec 9 03:46:11 2011 > New Revision: 3344 > URL: http://trac.networkupstools.org/projects/nut/changeset/3344 > > Log: > Force files to be overwritten (especially for libtool) > > Modified: > branches/nut-scanner_dlopen/autogen.sh > > Modified:
2008 Apr 10
1
Computing time when calling C functions - why does an extra function call induce such an overhead?
Dear list, I am a little puzzled by computing time in connection with calling C functions. With the function mysolve1 given below I solve Ax=B, where the actual matrix operation takes place in mysolve2. Doing this 5000 times takes 3.51 secs. However, if I move the actual matrix inversion part into mysolve1 (by uncommenting the two commented lines and skip the call to mysolve2) then the
2012 Jan 07
3
Mixed-commit problem solved
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,
2011 Dec 14
1
Still plugging away at the repo conversion
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
2012 Jan 11
0
Missing files on windows_port branch
I think this trunk-to-branch interior merge should be clean, but the merge logic correctly identifies some missing files in the reposurgeon output (checked in -pre7 and -pre4). They are in SVN on that branch, though (ignoring .gitignore for the time being). I only see one java file in scripts/java/jNut/src/main/java/org/networkupstools/jnut/ from reposurgeon.
2009 Jul 07
3
rake db:create:all error
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/.
2014 Dec 10
2
URL path match in ssh config
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
2009 Jul 09
6
rdiscount Deadlock !
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
2011 Dec 22
1
Repo conversion progress report
I am pleased to be able to report that reposurgeon's Subversion dump stream parser is now working well enough to produce a live git repo from the NUT history up to r3364. This didn't happen easily. The NUT repo is a wonderful test case, and by that I mean it was a stone bitch to get the stream parser to handle it. One class of problems was due to cv2svn, which did things with the
2011 Jun 24
1
[LLVMdev] MC-JIT (any progress?)
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 >
2010 Jul 19
7
[LLVMdev] MC-JIT
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 =