Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil SCM

fossil-scm.org

Post reply on HN
Print view View original

81–90 of 147 posts

Re: Fossil SCM

#81

Post by tacostakohashi »

gkya wrote: post #76
tacostakohashi wrote: post #64

Earlier quoted context omitted.

Hmm, really? It's hard to measure objectively... but my perception was always that there was an explosion of SCMs around the early-mid 2000s, after everybody got sick of CVS, but eventually Git won out and a lot of the alternatives / diversity in the space went away. Within short succession, there was Subversion, Arch, Darcs, Quilt, Bazaar, Mercurial. On the commercial side, perforce had a certain amount of traction,…

I firmly believe that GitHub has at least 40% role in git's success. Another 40% is Linus, and the remaining 20% is git's technical merits.

Sounds about right to me... but it's hard to decouple things so neatly. It wouldn't really be possible to create an SVNHub that worked as well as github.

Re: Fossil SCM

#82

Post by tacostakohashi »

qznc wrote: post #79
tacostakohashi wrote: post #68

Earlier quoted context omitted.

Without having looked into the details... I do rather like the idea of an SCM with a built-in ticketing / documentation (wiki / markdown rendering system). These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website -…

On the other hand, it does not make much sense for ticketing and documentation to be distributed. They inherently must be centralized for a project.

I disagree completely - I think these things have the same properties as source code.

Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.

Re: Fossil SCM

#83

Post by sytse »

pestaa wrote: post #2

GitLab contributors, please take note. Fossil's UI is very fast and the navigation is intuitive and discoverable. I know it's on the roadmap, but it is so often an afterthought.

Thanks, we're indeed working on making the UI faster in https://about.gitlab.com/2017/02/06/vue-big-plan/

I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation:

1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something.

2. Fossil timeline seems similar to GitLab Activity https://gitlab.com/gitlab-org/gitaly/activity

3. Fossil code seems similar to GitLab Repository https://gitlab.com/gitlab-org/gitaly/tree/master

4. Fossil docs seems similar to GitLab help https://gitlab.com/help (in this case, for other projects I think it has the documentation of the project, not sure what standard they use)

5. Fossil branches are in the GitLab repo view

6. Fossil tickets are similar to the GitLab issues view

7. Fossil wiki is similar to GitLab wiki

8. Fossil includes a download tab, in GitLab that would be the tags view https://gitlab.com/gitlab-org/gitaly/tags to download the repo (not sure if this is always to download Fossil or the specific project)

9. The Fossil "More..." link looks like a sitemap.

What would you change in GitLab to make it more discoverable?

Re: Fossil SCM

#84

Post by tokenizerrr »

djsumdog wrote: post #42
simplehuman wrote: post #13

Surprised to see no LDAP support. http://www.fossil-scm.org/index.html/tktview?name=ec667f74f8

From what I can tell from the issue, they're suggesting the load balancer or server you put in front of Fossil to do the authentication (which can hit LDAP/AD). Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.

> Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.

That seems like a terrible compromise.

Re: Fossil SCM

#86

Post by __david__ »

lvh wrote: post #66
OJFord wrote: post #62

Earlier quoted context omitted.

> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs) No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.

Do git's CLI UX choices buy it power? Or, conversely: does git checkout being for switching branches, creating branches (but not listing or deleting them), and also checking out files from the version at a ref (sometimes) mean that git gets useful new features?

Yes?

Having checkout handle creating branches is strictly a shortcut. The other option for the shortcut would be for `git branch` to sometimes alter state in your working directory (it currently never does this). The non-shortcut version (which works today) is to only create branches with `git branch` and only checkout branches with `git checkout`.

If you look at it from the perspective of "checkout is the thing that screws with your local working directory", it is organized logically.

Re: Fossil SCM

#87

Post by eslaught »

sytse wrote: post #83
pestaa wrote: post #2

GitLab contributors, please take note. Fossil's UI is very fast and the navigation is intuitive and discoverable. I know it's on the roadmap, but it is so often an afterthought.

Thanks, we're indeed working on making the UI faster in https://about.gitlab.com/2017/02/06/vue-big-plan/ I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation: 1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something. 2. Fossil timeline seems similar to GitLab Activity http…

The issue is not that Gitlab is missing any of the pieces. The issue, I believe, is the organization of such pieces so that you can find them intuitively.

This is admittedly a lot better in Gitlab today that it used to be. When I started, I literally could not figure out basic things like how to get to a specific repository inside of an organization. It also doesn't help that Gitlab has chosen to use its own jargon for each of the basic concepts. A "project" is a "repository" and a "group" is an "organization", etc. I can kind of grok it, but I sometimes do a double take when something isn't where I expect.

For example: In my mental model, "project" == "repository". But when I go to a project home page like say [1], I don't see a code browser or commit list, or options that obviously take me to either of those. Instead, I have to click the "Repository" tab first. (It turns out that tabs can have second-level tabs, which means those options are hidden initially and thus not discoverable.) But I thought a "project" was a "repository"?

I fully realize the Gitlab notion of "project" may be more general than just a "repository", but this is an example of the sort of cognitive dissonance that I get navigating around the site.

At this point I've mostly made peace with the Gitlab interface, so it's a bit hard for me to pull up examples like this now. And as I said above, the interface has improved. But when I first started using Gitlab, there were a lot of things like this (little points of cognitive dissonance) which made it seriously an uphill battle to even use the product.

[1]: https://gitlab.com/StanfordLegion/legion

Re: Fossil SCM

#88

Post by __david__ »

BeetleB wrote: post #36
jdmichal wrote: post #18

Earlier quoted context omitted.

Rebasing gives you a linear history instead of the diamonds non-rebased branching and merging gives you. I mean, that's the technical reason, anyway.

But that's what I'm trying to understand: The branched history was never a problem for me (although I do use a GUI for it).

For me I dislike branched history because each merge point can (accidentally) have extra non-merge code added and therefore should technically be code-reviewed, too. Git doesn't like showing merge commit diffs (even with `git log -p`) and so it's not easy to see how someone resolved their merge conflicts.

I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.

Re: Fossil SCM

#89

Post by masklinn »

bananaoomarang wrote: post #51
bachmeier wrote: post #40

Here's my story. I wanted to use version control on my research projects, but asking my collaborators to use Git was too much. They were supposed to figure out a staging area and pushing and pulling and then they'd get a bizarre error about a merge conflict. They'd do a search and Stack Overflow told them to type in an incantation. The repo is messed up, the collaborator goes back to email, and I'm left sorting throu…

This is a good point. I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is. I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c. Maybe this is to do with our desire for everything to be…

> I think once developers learn Git (or as much as they need to use), then they forget how esoteric the the cli tool is.

Some of us never forget. And "esoteric" is way to kind a word for that thing, it is abstraction leak made software.

Post reply on HN