4 ms·

> > While you shouldn't be working on multiple things, I and most other people I met, end up doing so > Fossil solves that with branches. Merging a branch into

> > While you shouldn't be working on multiple things, I and most other people I met, end up doing so > Fossil solves that with branches. Merging a branch into the trunk is equivalent to what Git calls pushing. git does the same thing, though sometimes you're working on two related things, but want to make 2 commits. > Git's normal working model is that your checkins are local first, then only optionally pushed back to the repo you cloned from. Because I may not own or be associated with the original repository? Are you saying I shouldn't work on code simply because I can't contact the original author? > The "guy in the room" doesn't ask for comment; he just drops his magnum opus into the trunk and says "deal with it." But again, if i'm working on something that necessitates breaking something while it's being fixed, you're saying to use a private branch, so what's the difference? > Because Fossil defaults to "autosync on", you can't check in a change on a branch that has upstream changes. Fossil simply won't allow it. (There's a "force" option, but it creates a special kind of branch called a fork, which has to be resolved at some point.) Git has the same ability to prevent forced pushes. I'm still not seeing your point. But also, none of this actually solves the issue that everything you're talking about are environmental and not inherent in the scm, i.e. testing. > This is why we have social mores and community standards of behavior. It is a good thing if the tools we use support those desirable behaviors. The tools shouldn't stand in your way when you want to make a coherent idea a single idea instead of multiple little, sometimes conflicting ideas. It seems to come down to if you believe you own your code and everyone should be "allowed" to work on your code, or if you believe that anyone should be able to work on code. (centralized vs federated).

wyoung2 11y ago
> I may not own or be associated with the original repository? Then you're doing federated development, and you should continue to use Git or another tool that supports that style of development as a first-class activity. Many years ago, I read that > 90% of all software development is in-house private stuff. (Billing systems, custom workflow management software, etc.) A big chunk of the rest is software for sale by a company. If you have federated development going on within the bounds of a single company, you've probably also got organizational silos, which is a problem. I suspect open source and SAAS have shifted that statistic in recent years, but I'd bet most software is still developed by a group of developers who all at least know each others' names, and can at least email each other, if not buttonhole each other at the water cooler. Other shifts in the market, such as from boxed software on retail shelves to app stores is a net zero in this discussion, since the software is still developed the same way. > It seems to come down to...centralized vs federated Yes. The popularity of Git has associated "DVCS" with federated development, but one of the points I'm trying to make is that you don't have to give up on the benefits of a centralized repository if you need a DVCS.
- jimktrains2 11y ago
  > Then you're doing federated development, and you should continue to use Git or another tool that supports that style of development as a first-class activity. So, let's say I want to work on an open source project done in fossil. Let's say I don't personally know anyone associated with the project, and kind of just want to play around with it and I'm not even sure I'll be able to fix any bugs or add any useful features, or I just want to hack on an idea I had. How do I do this? Private branches? Isn't that what git offers? Sure, if there is never an expectation of an outsider looking at or hacking on the code, then a non-federated tool might make sense, but in any situation where the code is suppose to be public, I don't understand where the advantage is (or why I would ever voluntarily learn fossil unless as employer required it).
  - wyoung2 11y ago
    > let's say I want to work on an open source project done in fossil....How do I do this? You clone the repo, open it into a working directory, and turn off autosync. Then all changes made to the repo affect only your local instance. If you think there's a chance that you might want to send your changes back upstream, you should probably work on a branch. Then when it comes time to send your changes to someone with checkin rights on the repo you cloned from, you can use a feature that is unique to Fossil, as far as I know, called bundles. (http://fossil-scm.org/xfer/help?cmd=bundle http://fossil-scm.org/xfer/help?cmd=bundle) It is essentially a slice of the Fossil repository that someone else can integrate into their own repo, not unlike a pull request on GitHub. I actually prefer to think of Fossil bundles as uber-patches, since they record not only the textual changes to the repo, but also file modes, the full checkin history, checkin comments, file removals and additions, etc. Basically, it fixes every weakness of patch(1). > I don't understand where the advantage is The advantages are listed on or linked from the front page of the Fossil web site: http://fossil-scm.org/ http://fossil-scm.org/ For me, the biggest single advantage is the simpler day-to-day working model, but maybe you will find another virtue that you prefer.

wyoung2 11y ago

> I may not own or be associated with the original repository? Then you're doing federated development, and you should continue to use Git or another tool that supports that style of development as a first-class activity. Many years ago, I read that > 90% of all software development is in-house private stuff. (Billing systems, custom workflow management software, etc.) A big chunk of the rest is software for sale by a company. If you have federated development going on within the bounds of a single company, you've probably also got organizational silos, which is a problem. I suspect open source and SAAS have shifted that statistic in recent years, but I'd bet most software is still developed by a group of developers who all at least know each others' names, and can at least email each other, if not buttonhole each other at the water cooler. Other shifts in the market, such as from boxed software on retail shelves to app stores is a net zero in this discussion, since the software is still developed the same way. > It seems to come down to...centralized vs federated Yes. The popularity of Git has associated "DVCS" with federated development, but one of the points I'm trying to make is that you don't have to give up on the benefits of a centralized repository if you need a DVCS.

jimktrains2 11y ago
> Then you're doing federated development, and you should continue to use Git or another tool that supports that style of development as a first-class activity. So, let's say I want to work on an open source project done in fossil. Let's say I don't personally know anyone associated with the project, and kind of just want to play around with it and I'm not even sure I'll be able to fix any bugs or add any useful features, or I just want to hack on an idea I had. How do I do this? Private branches? Isn't that what git offers? Sure, if there is never an expectation of an outsider looking at or hacking on the code, then a non-federated tool might make sense, but in any situation where the code is suppose to be public, I don't understand where the advantage is (or why I would ever voluntarily learn fossil unless as employer required it).
- wyoung2 11y ago
  > let's say I want to work on an open source project done in fossil....How do I do this? You clone the repo, open it into a working directory, and turn off autosync. Then all changes made to the repo affect only your local instance. If you think there's a chance that you might want to send your changes back upstream, you should probably work on a branch. Then when it comes time to send your changes to someone with checkin rights on the repo you cloned from, you can use a feature that is unique to Fossil, as far as I know, called bundles. (http://fossil-scm.org/xfer/help?cmd=bundle http://fossil-scm.org/xfer/help?cmd=bundle) It is essentially a slice of the Fossil repository that someone else can integrate into their own repo, not unlike a pull request on GitHub. I actually prefer to think of Fossil bundles as uber-patches, since they record not only the textual changes to the repo, but also file modes, the full checkin history, checkin comments, file removals and additions, etc. Basically, it fixes every weakness of patch(1). > I don't understand where the advantage is The advantages are listed on or linked from the front page of the Fossil web site: http://fossil-scm.org/ http://fossil-scm.org/ For me, the biggest single advantage is the simpler day-to-day working model, but maybe you will find another virtue that you prefer.