similar to: reposurgeon and svn:ignore on a newly added directory

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)

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

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

(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

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,

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

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

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.

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

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

Argh! habits are hard to change. I've fixed the message again on the server, to satisfy the git format... Arnaud -- Linux / Unix Expert R&D - Eaton - http://powerquality.eaton.com Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/ Debian Developer - http://www.debian.org Free Software Developer - http://arnaud.quette.free.fr/ 2012/1/23 Arnaud Quette <aquette

[please use reply-all to include the list. thanks!] On Mar 7, 2016, at 12:56 PM, Denis Serov <intrudo at outlook.com> wrote: > > Hi! > > I would like to ask about current state of Windows port. Is it frozen? It will be cool to know the plans :) > > Where are a lot of Windows-branches at GitHub. What is the most actual one? github/Windows-v2.6.5-7 is the most recent

On Jan 15, 2014, at 10:18 AM, Emilien KIA wrote: > 2014/1/15 Charles Lepple <clepple at gmail.com>: >> Emilien, >> >> just saw your commit in Buildbot for testing some Windows changes. That's great that someone is working on this again! >> We have had a few users ask for updates to the 2.6.5+ version of NUT for Windows. > > I am just fixing some bugs

2014/1/15 Charles Lepple <clepple at gmail.com>: > Emilien, > > just saw your commit in Buildbot for testing some Windows changes. That's great that someone is working on this again! > We have had a few users ask for updates to the 2.6.5+ version of NUT for Windows. I am just fixing some bugs and implementing some minor windows-specific features. > The problem is that

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

Hi, I think it would be easier to understand why you want this if you had a use case for having an svnsync clone. Aside from backing up the repository, it seems like a fairly useless thing: you can't do local commits and then upstream them and you can't do If you want the complete history of the repository, then a git clone of the git-svn mirror will give you this very cheaply and with

Emilien, just saw your commit in Buildbot for testing some Windows changes. That's great that someone is working on this again! We have had a few users ask for updates to the 2.6.5+ version of NUT for Windows. The problem is that we do not have a good branch in Git to work from. The windows_port branch got rebased, but since it has merge commits, it is a bit of a mess. I apologize for