Hi again,
Most of the time I try not to interact with people discuss.
However, I was astonished by what a community manager answered to another guy.
So I decided to give my opinion about it.
> « You admitted to not using branches, apparently because you don’t see the
> point of them in a single-developer project »
As a community manager if you said that to another guy, it means that he should
use branch even if he doesn't want to.
For example, I don't want to use branch but I prefer tags even if branch is
better. Tags have nothing to do with branches of course !
I just don't want branches because I prefer that all the stuffs are in ONE
branch (Master, trunk, head, whatever-you-call-it).
Of course, I've never said that using a branch is bad : if one said he doesn't
want, it's up to him.
>« Committing publicly, early, and often is objectively better, a fact that
>falls naturally out of the mathematics of control theory. »
Nope.
a) It is said that SQLite is not good at concurrency. Thanks God someone, not
me, dare to say that SQLite is not good when it comes to concurrency !
b) It creates higher server loads that should not occur.
c) it creates too much information so the Fossil file would grow too much for
no serious reasons.
d) I even guess that it may create merge issues if everyone works with the same
trunk and the same file (rare).
Who said that marketing (e.g. poll, good communication, etc) is not needed in
the Fossil realm ?
As you could all guess, I prefer not to read all the rest.I expect that some
people may read it and then give appropriate responses ...
Best Regards
K.PS: Have you read my unmet needs Warren ?
De : Warren Young <w...@etr-usa.com>
À : Fossil SCM user's discussion <fossil-users@lists.fossil-scm.org>
Envoyé le : Vendredi 21 octobre 2016 18h14
Objet : Re: [fossil-users] features I'd like to have in fossil
On Oct 21, 2016, at 10:02 AM, Nikita Borodikhin <elit...@gmail.com> wrote:
>
> == color support - review the change, history analysis ==
>
> One should not underestimate the significance of color on terminals these
> days, that's why both git and mercurial and a lot of tools have color support
> in their base distribution. It makes it much easier to spot the changes in a
> diff
For diff, simply install colordiff, which is almost certainly already packaged
for your OS. Then:
$ fossil set diff-command 'coloridff -wu'
$ fossil diff -r 2016-10-01 | less
> to group similar files together in a status report at a glance
Define “similar.” Do you just mean that all the modified files should group
together separate from the added files and such, or something different?
This is one of the areas where working code will speak louder than well-crafted
prose.
> == change sets - preparing the change ==
>
> I often end up having several sets of unrelated changes.
You admitted to not using branches, apparently because you don’t see the point
of them in a single-developer project. This is one good use for them.
That is, if you’re working on one feature and then see that you’ve gone off on
a tangent and are now building something unrelated, you can check the first
feature’s unfinished changes into a branch, then return to the trunk to work on
the second feature.
You’re using branches in this case to stash unfinished work without breaking
the trunk or admixing unrelated features in a single checkin.
> Working with git, I use staging area to collect the needed changes and group
> them together
I think the git staging area fights against team cohesiveness, primarily
serving the needs of the sort of developer who likes to go off and hide in
their office, not showing their work to their team members until it’s
“perfect.” Committing publicly, early, and often is objectively better, a fact
that falls naturally out of the mathematics of control theory.
I realize that this is not a problem for you, but I’d guess that more Fossil
users are on teams than not.
> subversion really shines here with its changelists
Some months ago, a proposal was made that I consider vastly superior to svn
change lists: a flag for the stash command that would let you select and reject
each hunk of the current diff interactively.
If you had three essentially unrelated changes in the current working copy, you
could stash all the hunks belonging to two of them, then test the third change
separately and check it in once you’re happy. Then you could “stash pop” and
repeat to polish the other two, one at a time.
It is important that this not be implemented in terms of checkin, since you
need to test each unrelated feature separately before checking it in.
> == grep - development support ==
>
> Often the projects building process leaves many temporary files in the
> working directory. I could grep over the directory using standard grep but
> then I have to filter out those temporary files created by my build system.
The solution to that is ag, The Silver Searcher:
http://geoff.greer.fm/ag/
If you’re looking for a project, it would be nice if someone would teach ag
about Fossil ignore rules. It already knows about git, hg, and svn.
Meanwhile, we have its built-in .agignore feature.
ag is awesome in many other ways. In addition to being much faster than grep
and with a shorter typical command line, it has much smarter defaults:
- color output
- case insensitive
- recursive on the current directory
- etc.
> == combined log - history ananlysis ==
>
> The most unusual thing about Fossil is that it does not have "log" command.
> There are two different commands to access file history - timeline and finfo,
> but all other systems use log command to access history of both files and
> directories, be it the root directory of the project or a subdirectory. In
> Fossil, there is no easy command line way to get the history of a subtree.
I initially missed that when moving from Fossil, but I retrained my muscle
memory quickly enough. I suppose it would be nice to have “fossil log” simply
for those who can’t or won’t use Fossil enough to retrain, though.
> Ticket d1b50f4d06579e43c24d0e35f9d28d9562e95126 is the perfect example of
> this.
Any unique prefix of a ticket ID will suffice. (The same goes for all Fossil
artifacts, in fact.) You don’t have to paste all 40 characters of the hash.
For ticket IDs, the first 4 or 5 characters should suffice.
It also would have been kind of you to give a URL rather than just the ticket
ID. Abbreviations are allowed here, too:
https://www.fossil-scm.org/index.html/tktview?name=d1b50
> == linear history - history analysis ==
>
> The other thing is that Fossil, like cvs, but unlike svn or git, shows global
> history, including changes committed to branches parallel to the currently
> checked out one.
I think this is a result of Fossil being so dependent on its web GUI: the
graphical timeline solves most of the problem here, and if you want to see one
branch in isolation, it’s a mouse click away.
There is a way to get the same effect on the command line, though:
$ fossil timeline ancestors current
That asks Fossil timeline to show only ancestors of the current checkout’s
branch.
You may want to wrap that up in an alias or script to get a shorter command.
Key to this solution is that Fossil has several special checkin names: current,
tip, next, previous, ckout, and root:branchname:
https://www.fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki
Learning these helps in many other situations.
> == relative revisions - history analysis ==
>
> In Fossil there is no way to refer to a parent of a revision, with the
> exception the parent of checked out revision.
Can you give examples of why you’d need to do this? I mean, what’s wrong with
“fossil up 1234abcd” between each diff? Is the problem simply that it changes
working directory contents? I don’t mean to trivialize that if so, I just want
to be clear on what you see as the problem.
The Fossil web UI has a semi-hidden feature to do this. Just click two bubbles
in the timeline and you get a diff page showing the changes between those two
versions.
> == diff for a revision - history analysis ==
>
> I often use "svn diff -c rev" and "git show rev" to show a single commit as a
> whole. Until recent Andy Bradford's change introducing --checkin option, the
> only way to achieve that in Fossil was to use "fossil diff --from parent_rev
> --to that_rev”.
I’m not seeing a request here. Are you calling our attention to this new
feature, or did you want something more than fossil diff --checkin?
> == "checkout as repository" ==
>
> most of the time I hardly use that at all
Yes, I agree; “fossil clone” should have much of the functionality of “git
clone”. Instead of cloning into a .git directory within the clone target, I
propose that it clone to a repository file in the target directory called
.fslrepo or _FSLREPO, as appropriate.
Examples:
$ fossil clone http://fossil-scm.org
Because you didn’t give a file name, it clones into fossil/.fslrepo and opens
.fslrepo in place within that directory. It gets “fossil” from the tarball and
zip file option in Admin > Configuration.
$ fossil clone http://fossil-scm.org trunk
Same as above, except that it uses the directory name “trunk” instead of
“fossil”, just like git does.
$ fossil clone --branch version-1.30 http://fossil-scm.org v1.30
Checks out the v1.30 feature branch into a directory of that name. (Without
the final argument, it would still use “fossil” as the clone directory name.)
This idea does create a potential ambiguity, in that the parameter after the
clone URL could either be a named Fossil repository file or a directory. I
propose that it be solved by enforcing the current reponame.fossil convention:
if the parameter ends in .fossil, it’s a file name, else it’s a directory name.
That could be extended to cover other common conventions in use. Does anyone
who has read this far use anything other than *.fossil?
One other detail: Fossil would need to behave as if .fslrepo and _FSLREPO are
always in the ignore lists. You wouldn’t want to nuke your working copy via
“fossil clean”.
> == wiki syntax ==
>
> I would appreciate a lot if there were links to the official wiki_rules and
> md_rules files.
You wouldn’t want a simple link, because that would throw away your wiki page
edits. What you want is a way to open those documents in-place as a sidebar,
or to open them in a separate tab.
_______________________________________________
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
