Hey Christopher,
On 3 March 2015 at 16:46, Christopher M. Fuhrman wrote:
> Howdy,
>
> You've got a typo. s/Sub-meun/Sub-menu/
>
More eyes makes all bugs shallow!
It looks like Dr. Hipp chose to go with a far less verbose hint:
https://www.fossil-scm.org/fossil/blame?filename=www/hints.wiki&chec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Howdy,
You've got a typo. s/Sub-meun/Sub-menu/
Cheers!
On Sun, 1 Mar 2015 at 1:14pm, jungle Boogie wrote:
> Hello All,
>
> Now that finding things on the timeline is easier, I propose the below
> diff for #5 here:
> https://www.fossil-scm.org/foss
On Tue, Mar 3, 2015 at 6:11 PM, Warren Young wrote:
> Yeah, it’s a bit broken. If file attributes are considered a part of the
> file’s data, and not just local metadata, then:
>
> chmod +x foo
> f ci foo
>
> should result in a checkin even if foo hasn’t otherwise changed.
>
Actually, the "
On 3/3/15, Ross Berteig wrote:
>
> On 3/3/2015 1:23 PM, Richie Adler wrote:
>> Petr Ferdus decía, en el mensaje "Re: [fossil-users] fossil repolist
>> argument
>> with winsrv" del 3/3/2015 18:15:56:
>>> BTW fossil server could serve *.fossil files from any subdirectory of
>>> directory it was
>>>
On 3/3/15, David Given wrote:
> I'd like to link to my project's README from my doc/index.wiki (via a
> .../doc/tip/README URL). Unfortunately, the README, not having an
> extension, is being sent as a application/octet-stream, which causes web
> browsers to treat it as binary rather than displayi
On 3/3/15, Warren Young wrote:
> If you say “fossil bundle import my.bundle”, then go inspect the changeset,
> there doesn’t seem to be a way to publish directly from that
> partially-merged state. It seems to require that you “purge” the changeset,
> then re-import with the --publish flag.
You
On Mar 3, 2015, at 4:00 PM, Ron W wrote:
>
> And neither "fossil changes" nor "fossil ci" did not warn me about that.
Yeah, it’s a bit broken. If file attributes are considered a part of the
file’s data, and not just local metadata, then:
chmod +x foo
f ci foo
should result in a checkin
On Tue, Mar 3, 2015 at 5:47 PM, Warren Young wrote:
> I assume you’re running into this on mixed Windows/Linux systems where
> Windows’ “archive” flag gets translated into a POSIX +x flag? If so, you
> don’t actually want the flag change checked in.
>
Yes. At work, we have a mixed environment.
On Mar 2, 2015, at 2:00 PM, Ron W wrote:
>
> In the check-in Info page, the changes section sometimes has "Execute
> permission set" lines. This confuses non-developer people. Is there a way to
> filter this out?
I’d prefer that Fossil just told you about this change during checkin, so you
ca
On Mar 2, 2015, at 5:30 AM, Richard Hipp wrote:
>
> The key idea would be to relax the requirement that each client load
> the entire history of the project. Instead, a clone would only load a
> limited amount of history (a month, a year, perhaps even just the most
> recent check-in).
This woul
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 a single step.
When I have suggested c
I completely agree to change current mv/rm commands so as they perform
the OS level operation too. It looks like an inconsistency that they
do not move/remove the file in the local repository and they
move/remove it in the cloned repositories.
If some script breaks, it can be repaired. No problem.
Something like a cmv, crm (these are off the top of my head, don't
dwell on the poor names) command that is "complete mv", and "complete
rm" would fit the bill, where it appropriately wraps the current mv/rm
commands is feasible, though.
-bch
On 3/3/15, Richard Hipp wrote:
> On 3/3/15, to...@ac
I just tried to use the new “fossil bundle” commands and came across an oddity
in the current implementation.
(Why not before? Because my only active public project is still in svn. There
is a private Fossil repo, but since no one is committing to it yet, I really
haven’t needed the feature y
I’m going to start two different reply forks: I’ll reply to the Pollack article
here, then send another message later to chime in on your proposal, drh.
On Mar 2, 2015, at 5:30 AM, Richard Hipp wrote:
>
> Ben Pollack's essay at
> http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-retur
I'd like to link to my project's README from my doc/index.wiki (via a
.../doc/tip/README URL). Unfortunately, the README, not having an
extension, is being sent as a application/octet-stream, which causes web
browsers to treat it as binary rather than displaying it.
Is there a way I can persuade F
Hello,
I tried the new "repolist" feature of ui/server/cgi. Neat addition.
There is a minor caveat, though: It does not work together with the
"notfound" setting. Trying to get the repository listing on "/" redirects
to the "notfound" URL, because this one is checked first. Wouldn't it be
better
On 3/3/2015 1:23 PM, Richie Adler wrote:
Petr Ferdus decía, en el mensaje "Re: [fossil-users] fossil repolist argument
with winsrv" del 3/3/2015 18:15:56:
BTW fossil server could serve *.fossil files from any subdirectory of
directory it was
invoked with.
From where I sit, this sounds like
On 3/3/15, to...@acm.org wrote:
> You could always have a global setting on how to deal with this (old way vs
> new way) to keep everyone happy :)
>
So nobody would ever know what the "mv" and "rm" commands actually do
without first consulting their settings. No. I think that is a very
bad solu
You could always have a global setting on how to deal with this (old way vs
new way) to keep everyone happy :)
-Original Message-
From: Richard Hipp
Sent: Tuesday, March 03, 2015 11:22 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Justification for two-step mv and rm
Petr Ferdus decía, en el mensaje "Re: [fossil-users] fossil repolist argument
with winsrv" del 3/3/2015 18:15:56:
> BTW fossil server could serve *.fossil files from any subdirectory of
> directory it was
> invoked with.
In order to do what you want, "fossil server" should iterate all the
direc
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 changing this, I got push back that the change
will break exi
> Od: Richie Adler
> Subject: Re: [fossil-users] fossil repolist argument with winsrv
>
>Petr Ferdus decía, en el mensaje "Re: [fossil-users] fossil repolist argument
>with winsrv" del 3/3/2015 17:13:44:
>
>> Is it correct/intentional? My hopes were that I would have "Available
>> Repositories:"
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.
I’ve written scripts to wrap these, but I won’t provide them here because they
don’t handle all of the cases properly.
Petr Ferdus decía, en el mensaje "Re: [fossil-users] fossil repolist argument
with winsrv" del 3/3/2015 17:13:44:
> Is it correct/intentional? My hopes were that I would have "Available
> Repositories:"
> displayed in any directory/subdirectory I browse into.
> Could be fossil repositories enume
> From: Richie Adler
> Subject: Re: [fossil-users] fossil repolist argument with winsrv
>
>Joe Mistachkin decía, en el mensaje "Re: [fossil-users] fossil repolist
>argument with winsrv" del 2/3/2015 19:48:22:
>
>> Sorry, minor oversight. It was not setting the right flag bit prior to
>> calling i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/2/2015 12:49 PM, Andy Goth wrote:
> On 2/24/2015 11:31 AM, Joe Prostko wrote:
>> Yes, I wondered about the directory name not matching the
>> filename, but just modified my Haiku build recipe to account for
>> it. I'll be sure to change the rec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This probably isn't news to anyone, just a gotcha that I ran into, and not for
the first time. Figured I'll describe it on the list and see if anyone has any
thoughts. This isn't a bug or anything; Fossil is behaving according to
design. It's jus
On Mon, Mar 02, 2015 at 05:53:25PM -0800, jungle Boogie wrote:
> Hello All,
>
> We're all familiar with the timeline:
> https://www.fossil-scm.org/index.html/timeline?y=ci
>
> But there's also the fine info that displays the history of a file:
> https://www.fossil-scm.org/index.html/finfo?name=sr
Sorry, clicked wrong button in eMail client -- should have been a new
thread not a reply...
Tontyna
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
The environment variable 'FOSSIL_HOME' introduced in 1.31 should be
documented:
Index: www/tech_overview.wiki
==
--- www/tech_overview.wiki
+++ www/tech_overview.wiki
@@ -131,8 +131,11 @@
database is named "_fossil" (using an under
On 2 March 2015 at 22:45, Tontyna wrote:
>
> And please: In the '2.0 Compiling/MinGW' paragraph a note about not using
> MinGW-4.0 cause it breaks e.g. the "extras" command:
thanks, added.
Michai
___
fossil-users mailing list
fossil-users@lists.fossil-
32 matches
Mail list logo
