On Sun, 26 Oct 2014 10:30:46 +0300
Baruch Burstein
wrote:
> On Sun, Oct 26, 2014 at 10:28 AM, Baruch Burstein
> wrote:
>
> > On Fri, Oct 24, 2014 at 4:58 PM, Ron W
> > wrote:
> >
> >> Not sure if anything in this might be helpful, but I found this:
> >>
> >> https://github.com/oopos/fossil/tre
On Sun, Oct 26, 2014 at 10:28 AM, Baruch Burstein
wrote:
> On Fri, Oct 24, 2014 at 4:58 PM, Ron W wrote:
>
>> Not sure if anything in this might be helpful, but I found this:
>>
>> https://github.com/oopos/fossil/tree/master/tools/cvs2fossil
>>
>
> I haven't looked at it yet, but it strikes me a
On Fri, Oct 24, 2014 at 4:58 PM, Ron W wrote:
> Not sure if anything in this might be helpful, but I found this:
>
> https://github.com/oopos/fossil/tree/master/tools/cvs2fossil
>
I haven't looked at it yet, but it strikes me as somewhat ironic that a
tool for converting CVS to Fossil is hosted
On Tue, Oct 21, 2014 at 5:30 PM, Ron W wrote:
> On Tue, Oct 21, 2014 at 5:32 AM, Baruch Burstein
> wrote:
>>
>> Done. As I said, It is *very* much a work-in-progress.
>>
>
> Looks like a good start. Not as much code as I thought it would require.
>
Baruch,
Not sure if anything in this might be
On 23 October 2014 12:26, Ron W wrote:
> Having read post from many places, one of the big complaints SVN users have
> about Git is directory tracking. Fossil lack this, too.
I had a weird related issue the other day (I would argue it's a bug, but YMMV).
I was moving an existing directory hierar
On Thu, Oct 23, 2014 at 7:26 PM, Ron W wrote:
> Also, another reason in favor of a direct importer: Git only tracks the
> heads of branches. No history is being lost, just that determining what
> branch a given commit belongs to is difficult. Therefor, git-fast-import
> doesn't provide branch nam
On Tue, Oct 21, 2014 at 5:30 PM, Ron W wrote:
> On Tue, Oct 21, 2014 at 5:32 AM, Baruch Burstein
> wrote:
>>
>> Done. As I said, It is *very* much a work-in-progress.
>>
>
> Looks like a good start. Not as much code as I thought it would require.
>
> A direct import will certainly bypass the lim
On Mon, 20 Oct 2014 18:37:46 -0400
Ron W wrote:
> Among other things, it can read SVN dump files and write
> git-fast-export files. Eric invested 2 years in the processing of SVN
> dump files, and is very aware of the issues with git-svn and svn2git,
> so I expect this is worth looking into.
Tod
On Tue, Oct 21, 2014 at 5:32 AM, Baruch Burstein
wrote:
>
> Done. As I said, It is *very* much a work-in-progress.
>
Looks like a good start. Not as much code as I thought it would require.
A direct import will certainly bypass the limitations of using
git-fast-import as an intermediate. Still w
On Mon, Oct 20, 2014 at 6:00 PM, Baruch Burstein
wrote:
> On Mon, Oct 20, 2014 at 4:39 PM, Ron W wrote:
>
>> Please make your in-progress SVN imported avilable.
>>
>
> I will try to do this later tonight
>
Done. As I said, It is *very* much a work-in-progress.
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹno
On Mon, Oct 20, 2014 at 6:42 PM, Andreas Kupries
wrote:
> Saw this on /. today
>
>
> http://developers.slashdot.org/story/14/10/20/217248/help-esr-stamp-out-cvs-and-svn-in-our-lifetime
That's what lead me to reposurgeon.
___
fossil-users mailing list
Saw this on /. today
http://developers.slashdot.org/story/14/10/20/217248/help-esr-stamp-out-cvs-and-svn-in-our-lifetime
On Mon, Oct 20, 2014 at 3:37 PM, Ron W wrote:
> On Fri, Oct 17, 2014 at 8:21 PM, Ron W wrote:
>>
>> Some SVN features not in Fossil
>
>
> My research was on hold (still is).
On Fri, Oct 17, 2014 at 8:21 PM, Ron W wrote:
> Some SVN features not in Fossil
>
My research was on hold (still is). Following a chain of posts elsewhere on
the web, I came across this:
http://www.catb.org/esr/reposurgeon/
Among other things, it can read SVN dump files and write git-fast-expo
On Mon, Oct 20, 2014 at 4:39 PM, Ron W wrote:
> Please make your in-progress SVN imported avilable.
>
I will try to do this later tonight
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-s
On Sun, Oct 19, 2014 at 3:51 AM, Baruch Burstein
wrote:
>
> I have been working recently (albeit slowly) on a 'fossil import --svn'
> option. I haven't pushed it since I didn't know if it would end up going
> anywhere, but if people are interested in seeing partial work, I can push
> it.
>
Pleas
On Sun, Oct 19, 2014 at 12:08 AM, Gour wrote:
> What about svn:externals? I know many projects, as well as the one in
> question, use them a lot?
>
> Any optimal way to do it with Fossil?
I had forgotten about externals in SVN.
I recall something about someone adding nested working space suppo
I have been working recently (albeit slowly) on a 'fossil import --svn'
option. I haven't pushed it since I didn't know if it would end up going
anywhere, but if people are interested in seeing partial work, I can push
it.
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
On Sat, 18 Oct 2014 16:42:11 -0400
Ron W wrote:
> SVN also allows properties on directories. But Fossil doesn't track
> directories, so can't support this.
What about svn:externals? I know many projects, as well as the one in
question, use them a lot?
Any optimal way to do it with Fossil?
Sin
On Sat, Oct 18, 2014 at 3:24 AM, Stephan Beal wrote:
>
> So the diff from SVN is that SVN tags the names whereas fossil tags a
> specific version. AFAIR we have no code in place to apply _propagating_
> tags to anything but commits, but i think that's just because we've never
> had a real use for
On Sat, Oct 18, 2014 at 9:04 AM, Stephan Beal wrote:
> On Sat, Oct 18, 2014 at 2:21 AM, Ron W wrote:
>
>> Tagging files. SVN allows properties to be attached to files as well as
>> to commits. SVN properties
>>
>
> [stephan@host:~/cvs/fossil/cwal]$ f-tag -a 67c37315814b -t file-test-tag
> -v 'te
On Sat, Oct 18, 2014 at 2:21 AM, Ron W wrote:
> Tagging files. SVN allows properties to be attached to files as well as to
> commits. SVN properties
>
Actually... in principle fossil allows tagging any artifacts (i.e. any
UUID), but no UIs have every been developed for anything beyond commit
tag
On Fri, Oct 17, 2014 at 6:42 AM, Gour wrote:
> In any case, my opinion is that having SVN <---> Fossil is much more
> interested than Git <---> Fossil 'cause, imho, with Fossil one can make
> very familiar/similar workflow like the one used with SVN.
Some SVN features not in Fossil:
Tagging fi
On Fri, Oct 17, 2014 at 6:30 PM, Ron W wrote:
>
> The main information the "post commit hook" method risks loosing is the
> relationship between a copied file and its copy, but Fossil doesn't have a
> copy command, so doesn't keep this, though I'm pretty sure it could.
>
Err, was too focused on t
On Fri, Oct 17, 2014 at 5:35 PM, Gour wrote:
> On Fri, 17 Oct 2014 16:00:08 -0400
> Ron W wrote:
> > Needing a break from dump file processing, I decided to look in to
> > how a mirror could be kept up to date.
>
> Thank you very much for taking time in doing this research...
Thank you for you
On Sat, 18 Oct 2014 00:12:07 +0200, Warren Young
wrote:
On Oct 15, 2014, at 2:18 PM, Stephan Beal wrote:
checkin [da524a7b522f] @ 2014-10-15 22:13:19 by [stephan] branch [trunk]
initial chicken.
On April 1, Fossil should use this as its default comment for commits to
new trees
On Oct 15, 2014, at 2:18 PM, Stephan Beal wrote:
> checkin [da524a7b522f] @ 2014-10-15 22:13:19 by [stephan] branch [trunk]
>
> initial chicken.
On April 1, Fossil should use this as its default comment for commits to new
trees.
___
fossil-user
On Fri, 17 Oct 2014 16:00:08 -0400
Ron W wrote:
Hello Ron,
> Needing a break from dump file processing, I decided to look in to
> how a mirror could be kept up to date.
Thank you very much for taking time in doing this research...
> Although this sounds like a "Rube Goldberg way" of doing it,
On Fri, Oct 17, 2014 at 3:25 PM, Ron W wrote:
> More research...
>
Needing a break from dump file processing, I decided to look in to how a
mirror could be kept up to date.
I previously mentioned using a commit monitor, so I looked to see how one
SVN repo could mirror another. I found svnsync.
On Thu, Oct 16, 2014 at 8:59 PM, Ron W wrote:
>
> After doing some research,
>
More research...
In the SVN dump file, deltas are optional, so an initial implementation can
omit dealing with deltas.
SVN dump files do not have manifests. There is a revision artifact followed
by file artifacts, so
On Thu, 16 Oct 2014 20:59:52 -0400
Ron W wrote:
> For a project that follows the recommended convention of directories
> named "trunk", "branches" and "tags" - or clearly identifies its
> convention - creating branches (and tagged commits) in Fossil should
> not be too hard. If the convention can
On Fri, Oct 17, 2014 at 2:59 AM, Ron W wrote:
> A question about libfossil: Is it possible to directly create a delta
> artifact? I ask this because it looks like SVN::Dump::Reader does not
> un-delta the artifact content. So either I would have to apply the delta
> myself (to provide the full te
On Wed, Oct 15, 2014 at 4:54 PM, Ron W wrote:
> But that's just the executive summary. The details will require much
> research, planning and design.
>
After doing some research, I was reminded that SVN branches (and tags) are
implemented as copy-by-reference. This means that the definition of a
On Wed, Oct 15, 2014 at 4:18 PM, Stephan Beal wrote:
> On Wed, Oct 15, 2014 at 10:11 PM, Ron W wrote:
>
>> Or I could try using libfossil to create a Fossil repo directly.
>>
>
> [stephan@host:~/tmp]$ f-new ron.fsl -m 'initial chicken.'
>
I mean that as my converter extracts files and metadata
On Wed, Oct 15, 2014 at 10:11 PM, Ron W wrote:
> Or I could try using libfossil to create a Fossil repo directly.
>
[stephan@host:~/tmp]$ f-new ron.fsl -m 'initial chicken.'
Created repository: ron.fsl
server-code= f107b37d27e8ede74a65e9ec99350509cd77c3f5
project-code = 047e669521ea219bbc4
On Wed, Oct 15, 2014 at 2:51 PM, Gour wrote:
> Well, I believe that Fossil could be interested for many SVN projects.
>
> The project which I converted has Git mirror which works with svn2git
> and every project users can see how does it feel using new (D)VCS. In
> that way, by not being able to
On Wed, 15 Oct 2014 13:30:05 -0400
Sean Woods wrote:
> I experimented with SVN to Fossil via Git a little over a year ago.
> It worked well for an initial export with no future imports, but for
> incremental updates it didn't work very well. The diffs were messed
> up. Here is the discussion fro
On Wed, 15 Oct 2014 13:23:56 -0400
Ron W wrote:
> The easiest way I have found, so far, to convert SVN to Fossil is via
> Git.
OK, that's what I was assuming.
> In theory, writing a SVN-dump to git-fast-export format converter
> could be done. If you want to have a near real time mirror of the
On Wed, Oct 15, 2014 at 1:30 PM, Sean Woods wrote:
> I wish the
> "gitmarks" feature was better supported in Fossil to have a true
> incremental import without scripting multiple version control systems.
> But, development efforts are probably better placed elsewhere.
Fossil support for increme
On Wed, Oct 15, 2014, at 01:23 PM, Ron W wrote:
> In theory, writing a SVN-dump to git-fast-export format converter could be
> done. If you want to have a near real time mirror of the SVN repo, you might
> have to create the Fossil repo that way because git-svn "maps" SVN branches
> and tags in
On Wed, Oct 15, 2014 at 4:51 AM, Gour wrote:
> As you know, migrating the project to new (D)VCS is never
> straightforward procedure without opposition from other camps mixed with
> politics. :-)
>
> However, natural step would be to provide Fossil mirror in order to show
> its adavantages over t
On Wed, Oct 15, 2014 at 10:51 AM, Gour wrote:
> $ fossil dbstat
> repository-size: 660814848 bytes (660.8MB)
> artifact-count:248761 (stored as 36568 full text and 212193 delta
> blobs)
> artifact-sizes:221499 average, 40470493 max, 55100155703 bytes
> (55.1GB) total
> compression-ratio
Hello,
I like Fossil and I'm using it for all my projects.
However, I would be glad that it would be used for many (open-source)
projects considering that it would be more suitable than Git(hub).
Recently I've re-awakened contact with the leader of one big FLOSS
project telling him more about Fo
42 matches
Mail list logo
