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
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
