similar to: Progress report on git conversion

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

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

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

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

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)

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,

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 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

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

All, We are considering removing some branches and tags in the conversion process from CVS to SVN. We don't want to do this in a vaccuum, so please read carefully. A deficiency in the cvs2svn script causes it to bloat the Subversion repository (significantly, as in 10x) in the conversion of branches and tags. We can minimize the impact of this by only keeping branches and tags that we really

Hi Reid, > A deficiency in the cvs2svn script causes it to bloat the Subversion > repository (significantly, as in 10x) in the conversion of branches > and tags. It's probably a bit late in the day, but have you considered other CVS to SVN conversion tools, e.g. Tailor? http://www.darcs.net/DarcsWiki/Tailor http://darcs.arstecnica.it/tailor/ Cheers, Ralph.

I've been wondering if we should consider migrating from CVS to Subversion (aka SVN) for version control. There's a utility (cvs2svn) to convert a CVS repository while keeping full history. And SVN is supported by viewcvs (as used by http://cvs.xapian.org/) The main motivations are: * CVS doesn't really handle renaming files well. Either you "cvs rm" then "cvs

So the Github-Importer screws up the old dark places of the SVN-History and the scripts try to handle this? 2017-01-13 22:57 GMT+01:00 James Y Knight via llvm-dev < llvm-dev at lists.llvm.org>: > I've been working on some scripting for re-converting the svn repository > into git. > > The existing git conversions are entirely sufficient for day-to-day > development

On Mar 20, 2004, at 1:07 PM, Ralph Giles wrote: > Ok, I'm starting the conversion. Please hold all commits until > further notice good luck! let me know how the cvs2svn script works out for you... I'm looking at doing the same soon with a ~800 file cvs repository I'm in charge of. /dale --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage:

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,

Reed, Can the "see" branch be renamed "SVA", for Secure Virtual Architecture? This is the new name of the LLVA system and project. It uses LLVM as the instruction set and compiler infrastructure. Thanks, --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Apr 2, 2007, at 1:08 PM, Reid Spencer wrote: > All, > > We are considering removing some

On Mon, 2007-04-02 at 13:30 -0500, Vikram S. Adve wrote: > Reed, > > Can the "see" branch be renamed "SVA", for Secure Virtual > Architecture? This is the new name of the LLVA system and project. > It uses LLVM as the instruction set and compiler infrastructure. Yes, we can do that. I'll add it to the conversion script. > > Thanks, > >

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