On Fri, 14 Dec 2012 20:26:33 -0800
Joe Mistachkin sql...@mistachkin.com wrote:
1. Retain the existing behavior for all current commands and
aliases. It is far too dangerous to change the DEFAULT semantics of
these commands now.
Does it imply that Fossil should not break backward comp. ever
On Sat, 15 Dec 2012 05:26:33 +0100, Joe Mistachkin sql...@mistachkin.com
wrote:
My opinion is that backward compatibility should be retained because
various
people, including several that may not be involved in this discussion,
have
existing scripts and other automation that relies upon
On Sat, 15 Dec 2012 03:15:09 +0100, Richard Hipp d...@sqlite.org wrote:
On Fri, Dec 14, 2012 at 8:58 PM, Themba Fletcher
themba.fletc...@gmail.comwrote:
Could I humbly suggest unmanage for the name of the
remove-from-repo-and-leave-the-disk-alone command? This would be
consistent with the
Gour wrote:
Does it imply that Fossil should not break backward comp. ever in
order to evolve in certain design choices which were, as Richard
himself stated the use of text/x-fossil-wiki for comment and ticket
text was a mistake. ?
In my opinion, breaking backward compatibility with a
j. v. d. hoff wrote:
I find this a confounding proposal.
Would you care to explain exactly what you find confounding about it?
It provides the requested functionality; however, it does so in a manner
that is respectful to those who are depending on the current functionality.
--
Joe
On Sat, 15 Dec 2012 10:56:20 +0100, Joe Mistachkin sql...@mistachkin.com
wrote:
j. v. d. hoff wrote:
I find this a confounding proposal.
Would you care to explain exactly what you find confounding about it?
has all been set way too often in this way too long thread:
POLS comes again
j. v. d. hoff wrote:
POLS comes again to mind.
The Principle of Least Surprise is not static. Changing the current
behavior
would be a huge (and potentially unpleasant) surprise for those who are very
actively using Fossil now.
I can tell you that I _was_ surprised (being also a user of
On Sat, 15 Dec 2012 12:03:26 +0100, Joe Mistachkin sql...@mistachkin.com
wrote:
j. v. d. hoff wrote:
POLS comes again to mind.
The Principle of Least Surprise is not static. Changing the current
behavior
would be a huge (and potentially unpleasant) surprise for those who are
very
On 12/15/12 05:26, Joe Mistachkin wrote:
My opinion is that backward compatibility should be retained because various
people, including several that may not be involved in this discussion, have
existing scripts and other automation that relies upon the current behavior.
I'm going to
On 12/15/12 11:24, j. v. d. hoff wrote:
[---]
and I do not buy the it'll be really dangerous for so many people
prophecy. of course, if one really tries hard one can manage to get
things messed up on disk (change lots of things in tracked files, but
don't ever check in (clever) and then
On Sat, 15 Dec 2012 12:52:34 +0100
Jan Danielsson
jan.m.daniels...@gmail.com wrote:
Obliterate has shun connotations for those who have used
Perforce, If we go with different names, I would prefer another name
for the commands.
Similar here...I know 'obliterate' from darcs and the
On Sat, Dec 15, 2012 at 2:41 AM, Themba Fletcher
themba.fletc...@gmail.comwrote:
I've been meaning to post this for a while. On every browser except
firefox, at least with my installed fonts, the side-by-side diff container
overflows the body resulting in the body's border being visible as a
The fossil repositories on core.tcl.tk, welll, most of them are reflected
to the github tcltk account/organization.
The scripts we are using for that were written by Pat Thoyts, and can
be found under /home/mirrors/gtof.
Richard (Hipp) has access to the machine and scripts.
Some of the locations
On Sat, 15 Dec 2012 01:52:11 +0100, Jan Danielsson jan.m.daniels...@gmail.com
wrote:
On 12/15/12 01:06, Eric wrote:
[---]
4) I am not criticizing people, merely what they say. I see evidence
that they don't get where I'm coming from because they have only an
incomplete idea of what this is
On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin c...@apotheon.net wrote:
Why do people feel insulted when it is suggested that they don't know
everything?
I know what SCM is, you condescending ass.
I believe you, but there are some here who don't know, and the message
is for everybody. And I
On Sat, Dec 15, 2012 at 05:15:17PM +, Eric wrote:
On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin c...@apotheon.net wrote:
Why do people feel insulted when it is suggested that they don't know
everything?
I know what SCM is, you condescending ass.
I believe you, but there are some
On 12/15/2012 03:52 AM, Jan Danielsson wrote:
On 12/15/12 05:26, Joe Mistachkin wrote:
My opinion is that backward compatibility should be retained because various
people, including several that may not be involved in this discussion, have
existing scripts and other automation that relies upon
On Fri, Dec 14, 2012 at 08:26:33PM -0800, Joe Mistachkin wrote:
My opinion is that backward compatibility should be retained because various
people, including several that may not be involved in this discussion, have
existing scripts and other automation that relies upon the current behavior.
On Sat, Dec 15, 2012 at 03:03:26AM -0800, Joe Mistachkin wrote:
j. v. d. hoff wrote:
POLS comes again to mind.
The Principle of Least Surprise is not static. Changing the current
behavior
would be a huge (and potentially unpleasant) surprise for those who are very
actively using
I would be interested in seeing the scripts for syncing with github as well!
Thanks,
Tomek
Date: Sat, 15 Dec 2012 17:20:11 +0100
From: andre...@activestate.com
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Syncing with Github
The fossil repositories on core.tcl.tk,
The latest debate over whether the 'rm' and 'mv'
commands--in the fossil shell--should behave exactly
line the 'rm' and 'mv' commands--in the various OS
command shells--proves one thing unequivocally:
Fossil is an piece of software that can spark vehement
opinions from its users. Fossil
Hello,
I found a few previous discussions about the implementation of full
text search in Fossil and I'm curious about the current status. It's
clear that this isn't a simple problem to solve, but I think it's an
essential feature to have, even if the initial implementation covers
just the most
Chad Perrin wrote:
If you are not ready for changes in default behavior, don't upgrade to
the next major version number. There is no good argument for software
defaults to be set in stone for all time. Just use reasonable caution
when releasing changes to default behavior.
That is
On 12/16/12 00:36, Joe Mistachkin wrote:
[---]
2. [---] On the other hand, if the
mv and rm commands were to perform their file system actions
prior to commit, would revert need to bring the previous files
back to life? That does not make sense.
Why not?
$ fossil rm
Jan Danielsson wrote:
First, I feel you're inventing problems to make arguments in order to
exclude features which address real world issues. (A little like the
script issue brought up earlier).
Straw man argument. Five yard penalty, still first down.
Second (slightly off-topic),
On 12/15/2012 06:28 PM, Joe Mistachkin wrote:
Jan Danielsson wrote:
First, I feel you're inventing problems to make arguments in order to
exclude features which address real world issues. (A little like the
script issue brought up earlier).
Straw man argument. Five yard penalty, still
On 12/16/12 03:28, Joe Mistachkin wrote:
First, I feel you're inventing problems to make arguments in order to
exclude features which address real world issues. (A little like the
script issue brought up earlier).
Straw man argument. Five yard penalty, still first down.
Still, I think
Hello,
I'm new to Fossil SCM, have not used any other SCMs, and am trying to do
something relatively complex for me. It involves moving from a model where
files are directly added to my repo, rather than being organized in the repo
within directories.
I had my project organized as:
project/
28 matches
Mail list logo
