similar to: Temporary git repo for the conversion metadata

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

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

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)

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,

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

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,

(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

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

Subtle bug, simple fix. The problem was introduced by my change that used content hashes to avoid issuing duplicate blobs. The generated .gitignore nodes didn't have a Content-Hash header, which meant all .gitignores were treated as though they had the same *empty* hash. 2.0pre8 is at: http://www.catb.org/esr/nut-conversion/nut-conversion.tar.gz Please check that the .gitignores look OK

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

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.

Dear NUT developers, As you all know, Eaton is NUT biggest corporate fan, supporting the project through many contributions. Now, Eaton would like to provide its customers with a way to build their own applications to interface with Eaton devices, using the NUT code-base. To do this, in a smart and efficient way (ie limiting additions and modifications to the bare minimum), we (Frederic and

Dear R list members, I'm encountering a problem with expand.model.frame(): Suppose that I define the following simple function (meant just to illustrate the problem): > fun <- function(model){ + expand.model.frame(model, all.vars(formula(model))) + } > and I have the following model, created with an explicit data argument: > mod Call:

I've solved the problem of the detached Eaton_SDK branch. What must have happened here is the branch creator did a non-Subversion cp -r followed by an add of the target directory. This registered a tree that duplicated trunk, *without* ancestry information connecting it to its source revision. The correct fix is to check each new text section against a list of MD5 hashes of old text

Dear R-help list members, I'm encountering problems using expand.model.frame. To illustrate, consider the function > test <- function(model){ + expand.model.frame(model, "income") + } > The data frame Prestige (from the car library) has several variables, including prestige, income and education. I've attached this data frame >

Dear R-devel list members, I'd like to suggest a more flexible procedure for generating contrast names. I apologise for a relatively long message -- I want my proposal to be clear. I've never liked the current approach. For example, the names generated by contr.treatment paste factor to level names with no separation between the two; contr.sum simply numbers contrasts (I recall an

Dear Trevor, I've noticed a discrepancy in the degrees of freedom reported by gam() from the gam package in R vs. gam() in S-PLUS. The nonparametric df differ by 1; otherwise (except for things that depend upon the df), the output is the same: --------- snip ------------ *** From R (gam version 0.93): > mod.gam <- gam(prestige ~ lo(income, span=.6), data=Prestige) >

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

I've encounted a problem using expand.model.frame. To illustrate, consider the function > test <- function(model){ + expand.model.frame(model, "income") + } > The data frame Prestige (from the car library) has several variables, including prestige, income and education. I've attached this data frame and fit the following model >