I'm sorry for the noise.
Trunk fossil works OK.
My old version hanged when server was down or unreachable (I'm behind proxy)
f pull http://bigcrush1.mooo.com
getaddrinfo() fails: Name or service not known
f pull http://bigcrush.mooo.com
hangs... [getaddrinfo() OK but connect() fails]
___
I fwiw have always found Fossil's mv and rm semantics odd. The following
semantics are basically what I expected when I first started using Fossil,
but extended to preserve backward compatibility. They basically do what
the user intended in all cases, do they not?
* fossil rm FILE:
* If FILE
It's back!
On 3/4/2015 3:08 PM, Andreas Kupries wrote:
The maintainer/hoster of chiselapp is Roy Keene
and I forwarded the initial mail to him a minute ago or so.
Thanks to some combination of bch, Andreas, and Roy, I'm happy to see
that chiselapp.com is back on line and serving up fossils.
On Wed, Mar 04, 2015 at 05:52:36PM -0700, Warren Young wrote:
> On Mar 4, 2015, at 5:28 PM, Francis Daly wrote:
> > On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote:
> > I think that the principle of least surprise for non-users of fossil is
> > (much) less important.
>
> I think the
Just to be clear: I don't yet know what I'm going to do about rm/mv.
But I am watching the discussion *very* closely and I deeply
appreciate the input. Thank you all. Please continue.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fo
On Mar 4, 2015, at 5:29 PM, Ron W wrote:
>
> On Wed, Mar 4, 2015 at 7:05 PM, Warren Young wrote:
> You can get the same effect without making yourself nervous with “fossil
> revert”.
>
> This not mentioned in "fossil help revert". It only says "Revert to the
> current repository version of FI
On Mar 4, 2015, at 5:28 PM, Francis Daly wrote:
>
> On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote:
>>
>>
>> The principle of least surprise says that Fossil should behave like other
>> VCSes.
>
> I think that the principle of least surprise for users of fossil is
> that the nex
On Wed, Mar 4, 2015 at 7:05 PM, Warren Young wrote:
>
> You can get the same effect without making yourself nervous with “fossil
> revert”.
This not mentioned in "fossil help revert". It only says "Revert to the
current repository version of FILE" or to specified version.
___
On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote:
> On Mar 4, 2015, at 3:27 PM, bch wrote:
Hi there,
> > Sure, but: fossil is distinct from the filesystems. DOS, ext, ffs,
> > etc., etc., etc are not versioning/managment filesystems, and there
> > ought to be a principle-of-least-sur
On Mar 4, 2015, at 4:50 PM, Ross Berteig wrote:
>
> It has always bothered me that the command that reverses 'add' is ‘rm'
You can get the same effect without making yourself nervous with “fossil
revert”. This matches the behavior of Mercurial, Subversion, and Bazaar.
hg forget does things yo
On Wed, Mar 4, 2015 at 5:18 PM, Warren Young wrote:
> Many filesystems and OSes combine file versioning and file management:
>
> https://en.wikipedia.org/wiki/Versioning_file_system
>
> In a sense, VCSes are a way to get such features on top of filesystems
> that lack these abilities.
Fossil
On Mar 4, 2015, at 4:08 PM, David Mason wrote:
>
> The only problem I
> see with rm is that, at first blush (looking at the table):
You’re correct. If you try to remove an added but uncommitted new file, hg
warns you:
not removing foo: file has been marked for add (use forget to undo)
hg f
On Wed, Mar 4, 2015 at 5:09 PM, Warren Young wrote:
> On Mar 4, 2015, at 10:24 AM, paul wrote:
> >
> > If fossil mv also moves files on a filesystem, I'd be happy with that,
> so long
> > as I can still use a file browser as I'm doing now.
>
> All other VCSes I’ve used that do one-step mv [*] co
On 3/4/2015 3:08 PM, David Mason wrote:
So I would endorse the change to "fossil rm" if we added a "fossil
forget" command.
Despite their similarities in many respects, 'mv' and 'rm' are different
in this one respect. It has always bothered me that the command that
reverses 'add' is 'rm', due
Every time I use fossil mv/rm, I've always had to issue the corresponding
mv/rm command (or equivalent commands in Windows). Can someone describe a
case where one would want to call fossil mv/rm, without intending the
referenced file to be moved/removed as well? To me, making fossil mv/rm
perform t
/me nods.
Thanks,
-bch
On 3/4/15, Andreas Kupries wrote:
> The maintainer/hoster of chiselapp is Roy Keene
> and I forwarded the initial mail to him a minute ago or so.
>
> On Wed, Mar 4, 2015 at 3:03 PM, bch wrote:
>> On 3/4/15, Ross Berteig wrote:
>>> I just tried to autosync with a repo
The maintainer/hoster of chiselapp is Roy Keene
and I forwarded the initial mail to him a minute ago or so.
On Wed, Mar 4, 2015 at 3:03 PM, bch wrote:
> On 3/4/15, Ross Berteig wrote:
>> I just tried to autosync with a repo I keep on chiselapp.com, and it
>> failed. I tried
>>
>>http://www.
I agree that making fossil semantics work the same as Hg would be
good. The change to mv looks perfectly reasonable. The only problem I
see with rm is that, at first blush (looking at the table):
hg rm -f foo
is the way to remove a newly added file. It's good, as in safe, but
it wouldn't occur
On 3/4/15, Ross Berteig wrote:
> I just tried to autosync with a repo I keep on chiselapp.com, and it
> failed. I tried
>
>http://www.downforeveryoneorjustme.com/chiselapp.com
>
> and it reports that http://chiselapp.com/ is not responding, so it
> clearly isn't *just* my ISP messing with me.
> Personally, I thought we were talking about practical UX stuff here, not
> philosophy.
That's not really fair -- this discussion is *couched* in applicable
philosophies.
On 3/4/15, Warren Young wrote:
> On Mar 4, 2015, at 3:27 PM, bch wrote:
>>
>>> Before you reject the idea of one-step rm t
On Mar 4, 2015, at 3:27 PM, bch wrote:
>
>> Before you reject the idea of one-step rm totally
>
> Oh, to be clear, I'm presenting this as a thought exercise.
If that’s all this is, we can send it to the philosophy department and move on
to other topics.
Personally, I thought we were talking a
I just tried to autosync with a repo I keep on chiselapp.com, and it
failed. I tried
http://www.downforeveryoneorjustme.com/chiselapp.com
and it reports that http://chiselapp.com/ is not responding, so it
clearly isn't *just* my ISP messing with me. I'm not sure who is
maintaining it curren
On Mar 3, 2015, at 4:49 PM, Richard Hipp wrote:
>
> just run the "fossil publish” command
Ah, I didn’t see that.
I do see that the help for some commands point to other related commands. I
propose adding:
See also: publish
to “help bundle”.
___
> Before you reject the idea of one-step rm totally
Oh, to be clear, I'm presenting this as a thought exercise.
> Many filesystems and OSes combine file versioning and file management
Sure, but: fossil is distinct from the filesystems. DOS, ext, ffs,
etc., etc., etc are not versioning/managment
On Mar 4, 2015, at 1:59 PM, bch wrote:
>
> What you're describing here is the crux of the problem, and I think
> can be fairly described as separation of concerns -- the domain of
> the version control is it's controlled files, and if a file is not
> handled by version control, (ie: fossil rm so
On Mar 4, 2015, at 1:52 PM, Martin Gagnon wrote:
>
> On Wed, Mar 04, 2015 at 06:33:07PM +0100, Ramon Ribó wrote:
>>
>> - When doing "fossil rm A"
>>
>> * If A exists in file system, delete file A
> This is another story. Sometimes, I just want to remove file from
> revision control
This is an
On Mar 4, 2015, at 10:24 AM, paul wrote:
>
> If fossil mv also moves files on a filesystem, I'd be happy with that, so long
> as I can still use a file browser as I'm doing now.
All other VCSes I’ve used that do one-step mv [*] cope with this case
transparently. They see that the on-disk file
On Mar 3, 2015, at 2:22 PM, Richard Hipp wrote:
>
> On 3/3/15, Warren Young wrote:
>> Is there a good reason that “fossil mv” and “fossil rm” must be followed by
>> OS-level mv and rm commands? I miss the behavior of Subversion which made
>> these into a single step.
>
> When I have suggested
On 04/03/15 00:56, Richard Hipp wrote:
[...]
> Try this: /doc/trunk/README?mimetype=text/plain
That's awesome --- thanks!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│
│ "Sufficiently advanced incompetence is indistinguishable from
│ malice." -- Vernon Schryver
signature.asc
D
What you're describing here is the crux of the problem, and I think
can be fairly described as separation of concerns -- the domain of
the version control is it's controlled files, and if a file is not
handled by version control, (ie: fossil rm somefile), should fossil be
reaching outside of its a
On Wed, Mar 04, 2015 at 06:33:07PM +0100, Ramon Ribó wrote:
> I think that both worlds can live together without any problem.
>
> - When doing "fossil mv A B"
>
> * If A exists and B does not exist in file system, rename file A to B
> * If B exists and A does not exist in file system, do nothing
Thus said Richard Hipp on Wed, 04 Mar 2015 08:13:23 -0500:
> > 2) fossil ignores 'http_proxy' but honors 'proxy' settings if set
> > manually strace shows that fossil hangs on sendto(-1, ...)
>
> I don't understand the problem statement here. And I don't have a
> proxy at hand for testing
Works great, thanks!
On Wed, Mar 4, 2015 at 6:18 PM, Richard Hipp wrote:
> On 3/4/15, Paolo Bolzoni wrote:
>> Dear list,
>>
>> I have a project that contains a tex file about a paper and the
>> relative C++ code.
>>
>> When I want to try some crazy idea I like to make a branch work
>> in it and
I think that both worlds can live together without any problem.
- When doing "fossil mv A B"
* If A exists and B does not exist in file system, rename file A to B
* If B exists and A does not exist in file system, do nothing
* If either both exist or none exists, warn and stop
- When doing "foss
On 03/03/15 22:27, j. van den hoff wrote:
On Tue, 03 Mar 2015 22:22:40 +0100, Richard Hipp wrote:
On 3/3/15, Warren Young wrote:
Is there a good reason that “fossil mv” and “fossil rm” must be
followed by
OS-level mv and rm commands? I miss the behavior of Subversion
which made
these into
On 3/4/15, Paolo Bolzoni wrote:
> Dear list,
>
> I have a project that contains a tex file about a paper and the
> relative C++ code.
>
> When I want to try some crazy idea I like to make a branch work
> in it and finally mergin in truck or closing depending how well
> it worked.
>
> But in this c
Dear list,
I have a project that contains a tex file about a paper and the
relative C++ code.
When I want to try some crazy idea I like to make a branch work
in it and finally mergin in truck or closing depending how well
it worked.
But in this case I want also to continue to work on the paper
t
On 3/4/15, Alexandr Smolnikov wrote:
> 1) On 'fossil set autosync off' I got "ambiguous setting "autosync" - might
> be: autosync autosync-tries
Fixed by https://www.fossil-scm.org/fossil/info/c94efdf287eb9695 on 2015-02-07
>
> 2) fossil ignores 'http_proxy' but honors 'proxy' settings if set ma
1) On 'fossil set autosync off' I got "ambiguous setting "autosync" - might
be: autosync autosync-tries
2) fossil ignores 'http_proxy' but honors 'proxy' settings if set manually
strace shows that fossil hangs on sendto(-1, ...)
All that happened after [32f8da0ce7] check-in
__
39 matches
Mail list logo
