The other day I converted a Subversion repository to Fossil via the
script presented at
http://www.fossil-scm.org/index.html/wiki?name=Cookbook#SVN . It mostly
worked, but the imported commits were not on the trunk branch. (By the
way, said Subversion repository did not utilize branching.)
On Tue, Mar 25, 2014 at 6:42 PM, Andy Goth andrew.m.g...@gmail.com wrote:
...but this somehow fractured the timeline with several commit manifests
having P cards naming nonexistent predecessors.
i was hopeful until you said that :/. Once an artifact referenced by other
artifacts is gone, if
On 3/25/2014 1:06 PM, Stephan Beal wrote:
i suspect a re-import from svn is the most expedient route here.
I had considered that, but the subversion repository is hard to get to.
It's on a private network my laptop cannot directly connect to without
the aid of janky security software, then
On 3/25/2014 1:23 PM, Andy Goth wrote:
I didn't know [fossil addremove] existed. That would have eliminated
the need for [fossil changes]! How convenient.
Here's an updated version of the script that uses [fossil addremove].
It also fixes a bug which included the user and tags in the
Fossil uses unique prefixes of checksums as identifiers. What does it
do when a previously-unique prefix becomes ambiguous due to a new commit?
Also, what happens when an existing comment (or ticket or wiki page or
whatever) references a no-longer-unique prefix? Fossil can't rewrite
the old
On 3/25/2014 4:40 PM, Andreas Kupries wrote:
On Tue, Mar 25, 2014 at 2:28 PM, Andy Goth andrew.m.g...@gmail.com wrote:
Fossil uses unique prefixes of checksums as identifiers.
No, it does not. Fossil stores full identifiers
I was referring only to the display. Full identifiers are usually
6 matches
Mail list logo
