On Oct 22, 2016, at 5:55 PM, K. Fossil user <ticketpersonnal-fos...@yahoo.fr> wrote: > > >« Branches in Fossil are just auto-propagating tags » > This is what they've said, technically at least. > For me this is not how I want it to be, because for most people tags are not > branches
Be concrete: how do you want tags to work which makes them entirely different from branches? Why is it a problem that Fossil branches are implemented in terms of auto-propagating tags? > (Marketing again). You keep misusing that word. Please take it as a fact from a native English speaker. Branches vs tags have nothing to do with “marketing.” > In another word, why am I using branches when as I've said tags suffice ? Both options exist because both have a reason to exist. I use both, each for very different purposes. > >« your typical Fossil server simply doesn’t have all that much concurrency > >going on.» > That is why I used to say that Git is better for big projects. I tried Googling to find out what Git’s concurrency model is, and got almost nothing useful. As far as I can tell, syncing to a remote repository locks the entire remote repository, making it *worse* than Fossil, not better. (SQLite concurrency locks only single tables, not the whole database, and then only for writes, not reads.) If you simply mean that Git operates the way Fossil does with autosync turned off, and thus each checkin doesn’t take resources on the central server, I’ll give you that. But again, I challenge you to show me a real use case where Fossil’s write locking causes an actual concurrency problem. > >« If you feel I’m wrong, go port Fossil to Oracle or whatever, and then > >we’ll see if it’s gotten faster. I think it’ll get slower, but you go and > >prove me wrong » > Oracle no. Another one will go faster if it is in a cluster. I’m completely missing your point, then. I understood your original complaint to be that Fossil’s use of SQLite is bad for concurrency, so I proposed that you port it to an Oracle DBMS, which has row-level locking, which would solve that objection. My contention is that you will get zero measurable improvement in Fossil performance when doing such a thing, which if true proves that SQLite is not the problem here. I’m not pushing Oracle specifically here. I make the same prediction for MySQL, MariaDB, Microsoft SQL Server, DB2, and PostgreSQL, all of which also do row-level locking. I’m talking about real-world use cases here, not benchmarks. If you have to artificially generate 1000 simultaneous checkins to show that system A is better than system B, that proves nothing, since virtually no project has checkin rates anywhere near that level. Even large projects generally have only dozens of checkins *per day*, which means that any given time, there is only zero or one checkin happening, which in turn means concurrency IS NOT A PROBLEM. > >Server loads that I've talked about... > Server loads will be higher if there are too many access (too many people too > many changes at the same time for example): and Fossil is a web server. The sqlite.org web site is served by Fossil. It seems pretty fast to me, despite the high number of hits it must serve every day. > too many access is not a big deal for git. :-D [citation needed] > >« Who did say that? » > a) People said that poll is not needed, in another word we don't need > marketing at all… Again you misuse that word. Polls are not “marketing.” A poll may feed information into the marketing process, but market research is not marketing itself. Anyway, proper scientific polling is seriously hard to do right. Just putting a poll on a web site is nearly useless from a scientific standpoint. (Look up “self-selection bias” if you don’t know why.) > b) Answering [...] feature set IS marketing, to be clear it IS communication. > Communication IS a set/portion/part of marketing. You know it’s time for a thread to die when we have to resort to the dictionary for rebuttals, but since this is likely to be my last reply to this thread, this might as well be the cap on it: https://www.wordnik.com/words/marketing Notice that there is no discussion of communication, responding to user complaints and requests, or triaging bug reports. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
