Just a heads-up:
I did a quick test, and this didn't seem to work:
* Created a new Fossil repository
* Opened it into ./fossil, added README.txt with contents "foo".
* Changed to parent directory, created Git repository in ./git
* Imported Fossil repo and switched to trunk branch
* Modified README.txt to contain "foo\nbar" and committed to Git
* Ran "git fast-export --all |fossil import --incremental ../test.fossil"
* Then ran "cd ../fossil; fossil up"
The result is that my initial commit of README.txt into Fossil appears
in the timeline twice. The Git commit appears, but "fossil up" won't
update to it, at least not without being explicitly asked. If you'd like
to see the resulting repository, it's here:
http://dl.dropbox.com/u/147071/test.fossil
Sorry I didn't test in the first place, I thought that the answer would
be something like "yes of course that works, that's what --incremental
does, what a silly question." :) I guess I'll just use Fossil until I
get pushback, then try promoting it and, if that fails, just export to Git.
Thanks.
On 11/04/2011 03:35 PM, Michael Barrow wrote:
Apologies in advance if this makes no sense. I've only done a tiny bit
with git and that was some time ago.
What if you have a single directory that both version control systems
use? You pull from git, commit to Fossil, do your changes and commit
to Fossil, and then push your changes to git. When you do the new pull
from git, you just update Fossil and start the cycle again.
--
Michael L. Barrow
On Nov 4, 2011, at 10:54, Nolan Darilek <no...@thewordnerd.info
<mailto:no...@thewordnerd.info>> wrote:
Thanks, but that's not really what I asked.
I totally get Fossil's development model, have used it for over a
year and think that it'd be a great fit for this particular
community. I also read this message when it was originally posted.
But I may be working with people who would rather submit a quick
change via Github rather than download and install a new piece of
software. Yes, I get that it's easy, I'm just thinking that it might
be a barrier here. So let me make the question more explicit:
1. Can I export my project to a Git repository, push that to Github,
make a few commits, export the changes to Git and push the repository
again? If so, will it look identical to the repository after the
first step with a few extra commits such that someone who pulls
doesn't get told that the repository after the changes is different?
2. If my canonical Fossil repository advances and someone makes
changes on Github, can I do an incremental import of the Git
repository and only get their changes without creating an entirely
new Fossil repository?
3. Has anyone else done this, and how does it work? I'd really rather
use Fossil, but am worried about losing contributors who don't want
to learn a new and simpler system. Since we're developing
applications to meet immediate needs (software for the various
occupations), the response I may get from people might be to use the
tools that everyone knows to maximize the community's
ability/willingness to chip in. If that response comes, hopefully I
can say that Fossil interacts with Git in the manner I've described
here and can meet the need.
Thanks.
On 11/04/2011 12:06 PM, Stephan Beal wrote:
On Fri, Nov 4, 2011 at 5:43 PM, Nolan Darilek
<no...@thewordnerd.info <mailto:no...@thewordnerd.info>> wrote:
some pushback from Git users. Is it possible to use Fossil in a
workflow with people who would rather use Git/Github?
Richard wrote a nice summary of that on Oct 16th which i'll paste in
here:
---------------
Fossil does not currently support a hierarchical development model
very well. It wants everybody to be a peer. It wants all
developers to see everything all the time. Fossil strives to avoid
a "peeking order" in which some developers are hidden from view
behind "lieutenants". This is a more egalitarian model, but also
one that does not scale as well.
To better support a hierarchy, Fossil would need the ability to sync
individual branches in addition to its current behavior of always
syncing everything on every sync request. (Recall that I asked for
volunteers to implement such a thing a while back.) But adding that
feature quickly gets complicated when you then try to figure out how
to deal with auto-sync. You could, I suppose, put your local Fossil
into a mode where it only syncs the branch you are currently working
on or switching to. But what about Wiki and Tickets and Events? Do
they get synced or not? Once you leave the comfort of Fossils
original model of "everybody sees all the code all the time" then
various operational questions of this kind start to come up.
---------------
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
<mailto:fossil-users@lists.fossil-scm.org>
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
