Re: [fossil-users] make fossil up 'quiter'
On Thu, February 9, 2012 7:47 am, Konstantin Khomoutov wrote: On Thu, Feb 09, 2012 at 01:55:01AM +0100, frantisek holop wrote: fossil always reports the latest artifact ID and commit message whenever doing 'fossil up', even though actually there was no new check-in. for example: $ fossil up Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 177 2 0 0 Received:2608 57 0 0 Total network traffic: 319 bytes sent, 1565 bytes received -- updated-to: 9b1d394a719f00f5a293612fe824e1a1fb1ed2e4 2012-02-08 03:04:23 UTC tags: trunk comment: Update the version number to 1.22 and begin entering change log information for the next release. (user: drh) this confuses me sometimes thinking there was a new check-in :[ wouldn't it be more natural not to print anything if the local check-out is exactly as the remote one? and have this repeating output as part of the --verbose output? what do you think? While I agree with you on this topic, a relatively easy way to spot that there probably was a check-in is to look for non-zero count in the Deltas column in the Received row. Non-zero Artifacts count means that there were *some* changes, but they could relate to anything (bugs filed, their state changed, wiki changes etc), and non-zero Deltas indicates some files managed by fossil has been changed. Having said that, an output akin to Git's one would be way more helpful in the general case: the list of branches which received updates with symbolic indication about the kind of update occured. fossil update is concerned only with the branch you have in your checkout directory. If autosync is on it does a pull first, but that's a separate operation, and it os concerned only with artifacts in the repository and knows nothing about branches. I wish people would stop expecting fossil to behave like git, if it did you might as well use git. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] make fossil up 'quiter'
hmm, on Thu, Feb 09, 2012 at 08:19:36AM -, Eric said that fossil update is concerned only with the branch you have in your checkout directory. If autosync is on it does a pull first, but that's a separate operation, and it os concerned only with artifacts in the repository and knows nothing about branches. I wish people would stop expecting fossil to behave like git, if it did you might as well use git. i have never used git. i would simply prefer fossil to report nothing if there is nothing to report... $ fossil up $ come to think of it, as a developer i am not really interested in fossil's traffic statistics either, it is more distracting than useful and would expect such extra information under --verbose. perhaps my minimalism is too maximal :] regarding git, i think it's not unreasonable to compare programs that in one way or the other server the same purpose, no? no need to be touchy about it. -f -- the greatest hate springs from the greatest love. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] make fossil up 'quiter'
Le 2012-02-09 à 05:04, frantisek holop min...@obiit.org a écrit : hmm, on Thu, Feb 09, 2012 at 08:19:36AM -, Eric said that fossil update is concerned only with the branch you have in your checkout directory. If autosync is on it does a pull first, but that's a separate operation, and it os concerned only with artifacts in the repository and knows nothing about branches. I wish people would stop expecting fossil to behave like git, if it did you might as well use git. i have never used git. i would simply prefer fossil to report nothing if there is nothing to report... $ fossil up $ come to think of it, as a developer i am not really interested in fossil's traffic statistics either, it is more distracting than useful and would expect such extra information under --verbose. perhaps my minimalism is too maximal :] That's might be a good output when autosync is off. But if autosync is ON, we should see something related to the sync step. Indeed, the sync step (or pull/push) might be slimmed a bit too. I would suggest only a progress or a counter refreshing a single line (using \r), so we can see if there's activity. If the sync step have no output, one might confuse very long sync with network timeout and an impatient will CTRL-C too early. -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] make fossil up 'quiter'
hmm, on Thu, Feb 09, 2012 at 05:58:47AM -0500, Martin Gagnon said that i have never used git. i would simply prefer fossil to report nothing if there is nothing to report... $ fossil up $ come to think of it, as a developer i am not really interested in fossil's traffic statistics either, it is more distracting than useful and would expect such extra information under --verbose. perhaps my minimalism is too maximal :] That's might be a good output when autosync is off. But if autosync is ON, we should see something related to the sync step. Indeed, the sync step (or pull/push) might be slimmed a bit too. I would suggest only a progress or a counter refreshing a single line (using \r), so we can see if there's activity. If the sync step have no output, one might confuse very long sync with network timeout and an impatient will CTRL-C too early. by all means, if there is some activity (pulling and/or pushing), report it. but the case i was referring to is when i am pushing nothing, and pulling nothing. as fossil returns to shell right away, i think the outcome is clear. regarding the network timeouts, no program reports them until they time out :] -f -- if you live long enough, it will kill you... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] make fossil up 'quiter'
On Thu, 9 Feb 2012 08:19:36 - Eric e...@deptj.eu wrote: [...] $ fossil up Autosync: http://www.fossil-scm.org/ Bytes Cards Artifacts Deltas Sent: 177 2 0 0 Received:2608 57 0 0 Total network traffic: 319 bytes sent, 1565 bytes received [...] While I agree with you on this topic, a relatively easy way to spot that there probably was a check-in is to look for non-zero count in the Deltas column in the Received row. Non-zero Artifacts count means that there were *some* changes, but they could relate to anything (bugs filed, their state changed, wiki changes etc), and non-zero Deltas indicates some files managed by fossil has been changed. Having said that, an output akin to Git's one would be way more helpful in the general case: the list of branches which received updates with symbolic indication about the kind of update occured. fossil update is concerned only with the branch you have in your checkout directory. If autosync is on it does a pull first, but that's a separate operation, and it os concerned only with artifacts in the repository and knows nothing about branches. The case presented by the original poster involved the pull step which appears to have suboptimal approach to reporting what we got from the remote repository. If you have autosync turned off (as I do everywhere, for instance) I just pull by hand, which changes nothing in this regard. That's why I referred to Git which, when you do pulling (it's called fetching in Git lingo) tells you artifacts for which branches it received, so you have an immediate idea about what has been changed on the remote. Hence my reference had nothing to do with Git's *workflow* in particular. I wish people would stop expecting fossil to behave like git, if it did you might as well use git. Please keep religious zealotry out of this list. Or at least try not to express it unless you are 100% sure you understood what the person to whose message you're responding to wanted to state. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] _FOSSIL_ file grows large
On Feb 8, 2012, at 17:05 , Richard Hipp wrote: I generally don't stress over a 10MB file on my 1TB disk drive, though... Still, it probably would not hurt to have Fossil do vacuum from time to time, would it? Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] zip/tar patch
On Feb 7, 2012, at 23:11 , Stephan Beal wrote: Agreed completely - spaces in filenames are evil. (let the flame wars begin ;) Well, shouldn't a good filename start with - anyways? ;) Kind regards, Remigiusz Modrzejewski ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] zip/tar patch
On Thu, Feb 9, 2012 at 6:08 PM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: Well, shouldn't a good filename start with - anyways? ;) i once administered a Solaris system where someone accidentally managed, over a serial terminal, to touch a new file whos name was a single backspace character (ASCII 0x08). The only way we managed to delete it was deleting its parent directory. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] zip/tar patch
On Fri, Feb 10, 2012 at 02:26, Stephan Beal sgb...@googlemail.com wrote:
i once administered a Solaris system where someone accidentally managed,
over a serial terminal, to touch a new file whos name was a single
backspace character (ASCII 0x08). The only way we managed to delete it was
deleting its parent directory.
Using Zsh on Linux, I can delete the file by 'rm ^H'.
('^H' is typed as ctrl-v ctrl-h.)
Also, 'rm ?' will do (after getting other single-letter-named files out).
--
MIURA Masahiro
echocham...@gmail.com
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] zip/tar patch
hmm, on Fri, Feb 10, 2012 at 03:12:01AM +0900, MIURA Masahiro said that
On Fri, Feb 10, 2012 at 02:26, Stephan Beal sgb...@googlemail.com wrote:
i once administered a Solaris system where someone accidentally managed,
over a serial terminal, to touch a new file whos name was a single
backspace character (ASCII 0x08). The only way we managed to delete it was
deleting its parent directory.
Using Zsh on Linux, I can delete the file by 'rm ^H'.
('^H' is typed as ctrl-v ctrl-h.)
Also, 'rm ?' will do (after getting other single-letter-named files out).
getting off-topic i am afraid, but it's also possible to delete
any fancy named files/directories by its inode :]
-f
--
god? i'm no god. god has mercy.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] make fossil up 'quiter'
On Thu, 9 Feb 2012 17:02:19 +0400, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Thu, 9 Feb 2012 08:19:36 - Eric e...@deptj.eu wrote: snip fossil update is concerned only with the branch you have in your checkout directory. If autosync is on it does a pull first, but that's a separate operation, and it is concerned only with artifacts in the repository and knows nothing about branches. The case presented by the original poster involved the pull step which appears to have suboptimal approach to reporting what we got from the remote repository. If you have autosync turned off (as I do everywhere, for instance) I just pull by hand, which changes nothing in this regard. That's why I referred to Git which, when you do pulling (it's called fetching in Git lingo) tells you artifacts for which branches it received, so you have an immediate idea about what has been changed on the remote. Hence my reference had nothing to do with Git's *workflow* in particular. It was not obvious whether you or the OP understood that this was a two-part process. Clearly you do. I really don't know why you say suboptimal - there's nothing wrong with preferring a different behaviour, but suboptimal is a whole different argument. I wish people would stop expecting fossil to behave like git, if it did you might as well use git. Please keep religious zealotry out of this list. And you tell me to be sure I understand the intentions of a poster before I respond! No religious zealotry at all, but a fragment of a rational argument, namely that many people suggest git-like things without understanding why git and fossil are different, or that design differences make some things easy in one and hard in the other, or that it might be good to take a different approach, or that it might be a matter of opinion which is right and which is wrong. I think that too much of that sort of thing has the potential to harm fossil. Most of the above may not apply to you specifically, but it looked as if it did; I can only respond to what I see. Or at least try not to express it unless you are 100% sure you understood what the person to whose message you're responding to wanted to state. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil commit failure after merge
Hi List, I ran into a strange problem which results in fossil commit failure after a specific type of merge. I attached a self-contained shell script that reproduces the problem. Tested with trunk version of fossil on Linux. Here is the problem description. A fossil repository T.fossil contains two brunches trunk and next. In both branches there are two files foo and bar. At some point in development process I merge branch next into the trunk. The contents of the files are such that fossil merge next successfully auto-merges changes in bar but has merge conflicts in foo that has to be manually resolved. So far so good. $ fossil cha UPDATED_BY_MERGE bar EDITED foo The project's internal logic dictates that while fixing merge conflicts in foo I have to make some changes to bar. After any changes to bar fossil refuses to commit claiming that working checkout does not match what would have ended up in the repository. I think this behavior is incorrect, for it forces me to commit a broken state of the project. Please, run an attached shell script to reproduce the problem. --Leo-- merge-conflict.sh Description: Bourne shell script ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil commit failure after merge
+1 I faced this a couple of days back and had to perform an incorrect commit. - Original Message - From: Leo Razoumov Sent: 02/10/12 03:39 AM To: Fossil SCM user's discussion Subject: [fossil-users] fossil commit failure after merge Hi List, I ran into a strange problem which results in fossil commit failure after a specific type of merge. I attached a self-contained shell script that reproduces the problem. Tested with trunk version of fossil on Linux. Here is the problem description. A fossil repository T.fossil contains two brunches trunk and next. In both branches there are two files foo and bar. At some point in development process I merge branch next into the trunk. The contents of the files are such that fossil merge next successfully auto-merges changes in bar but has merge conflicts in foo that has to be manually resolved. So far so good. $ fossil cha UPDATED_BY_MERGE bar EDITED foo The project's internal logic dictates that while fixing merge conflicts in foo I have to make some changes to bar. After any changes to bar fossil refuses to commit claiming that working checkout does not match what would have ended up in the repository. I think this behavior is incorrect, for it forces me to commit a broken state of the project. Please, run an attached shell script to reproduce the problem. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil commit failure after merge
On Thu, Feb 9, 2012 at 23:27, altufa...@mail.com wrote: +1 I faced this a couple of days back and had to perform an incorrect commit. Thanks for confirming my observations. I think this is a serious issue. I try to follow a policy of never committing to a public branch code that does not compile. Now this policy cannot be followed in some cases. And secondly such inconsistent commits break bisect. --Leo-- - Original Message - From: Leo Razoumov Sent: 02/10/12 03:39 AM To: Fossil SCM user's discussion Subject: [fossil-users] fossil commit failure after merge Hi List, I ran into a strange problem which results in fossil commit failure after a specific type of merge. I attached a self-contained shell script that reproduces the problem. Tested with trunk version of fossil on Linux. Here is the problem description. A fossil repository T.fossil contains two brunches trunk and next. In both branches there are two files foo and bar. At some point in development process I merge branch next into the trunk. The contents of the files are such that fossil merge next successfully auto-merges changes in bar but has merge conflicts in foo that has to be manually resolved. So far so good. $ fossil cha UPDATED_BY_MERGE bar EDITED foo The project's internal logic dictates that while fixing merge conflicts in foo I have to make some changes to bar. After any changes to bar fossil refuses to commit claiming that working checkout does not match what would have ended up in the repository. I think this behavior is incorrect, for it forces me to commit a broken state of the project. Please, run an attached shell script to reproduce the problem. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
