I already stumbled a couple of times over the fact that `fossil rm' and
`fossil mv' only act
on the repository but not on the check out, i.e. I always have to issue
two commands
in order to actually remove a file from the (future of) the project.
obviously this is different from other VCSs bu
On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff
wrote:
> I already stumbled a couple of times over the fact that `fossil rm' and
> `fossil mv' only act
> on the repository but not on the check out, i.e. I always have to issue
> two commands
> in order to actually remove a file from the (future of
On Nov 20, 2012, at 14:45 , Richard Hipp wrote:
> CVS did not couple the actions, and I copied CVS in this regard. I agree
> with you now, that coupling them is the right thing to do. But I fear to
> change it because that might cause problems for existing scripts.
This calls for making it a s
On Tue, 20 Nov 2012 15:00:29 +0100, Remigiusz Modrzejewski
wrote:
On Nov 20, 2012, at 14:45 , Richard Hipp wrote:
CVS did not couple the actions, and I copied CVS in this regard. I
agree
with you now, that coupling them is the right thing to do. But I fear
to
change it because that m
On Tue, Nov 20, 2012 at 6:45 AM, Richard Hipp wrote:
>
>
> On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff <
> veedeeh...@googlemail.com> wrote:
>
>> I already stumbled a couple of times over the fact that `fossil rm' and
>> `fossil mv' only act
>> on the repository but not on the check out, i.e
Richard Hipp wrote:
[...]
> CVS did not couple the actions, and I copied CVS in this regard. I
> agree with you now, that coupling them is the right thing to do. But I
> fear to change it because that might cause problems for existing scripts.
Add a -p for physical option to actually change the
On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote:
> Richard Hipp wrote:
> [...]
> > CVS did not couple the actions, and I copied CVS in this regard. I
> > agree with you now, that coupling them is the right thing to do. But I
> > fear to change it because that might cause problems for
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
wrote:
On Tue, Nov 20, 2012 at 03:39:06PM +, David Given wrote:
Richard Hipp wrote:
[...]
> CVS did not couple the actions, and I copied CVS in this regard. I
> agree with you now, that coupling them is the right thing to do. But
I
> f
On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:
> On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
> >
> >I'd suggest -f like cvs rm uses.
>
> obviously everybody seems to have his/her own preference how to
> handle this. so only a fraction of users will be happy in the end it
> s
On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin wrote:
On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:
On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
>
>I'd suggest -f like cvs rm uses.
obviously everybody seems to have his/her own preference how to
handle this. so only a f
Weighing in on this, finally:
It's interesting to me that everyone speculates that this *might* break
things for some hypothetical person, and *might* bite someone, but has
anyone here ever been bitten by it?
And is it not something that "fossil revert" could undo?
I don't mind avoiding the
Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.
On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek wrote:
> Weighing in on this, finally:
>
> It's interesting to me that everyone speculates that this *might* break
> things for some hypothetical person, and *migh
I agree with Themba. I like that Fossil is a separate repo 'world' from my
files. If this boundary is to be pierced, I think it should require passing in
some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in this
example representing "sync".
I would like some friendly tip text
On Tue, Dec 11, 2012 at 3:08 PM, K wrote:
> I agree with Themba. I like that Fossil is a separate repo 'world' from my
> files. If this boundary is to be pierced, I think it should require passing
> in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in
> this example represen
On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher
wrote:
Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.
On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek
wrote:
Weighing in on this, finally:
It's interesting to me that everyone speculates that this
On 12/11/12 23:08, K wrote:
> I agree with Themba. I like that Fossil is a separate repo 'world' from my
> files. If this boundary is to be pierced, I think it should require passing
> in some kind of explicit switch to cause it. eg., ./fossil -s rm ..., s in
> this example representing "sync".
On Wed, Dec 12, 2012 at 1:24 AM, Jan Danielsson
wrote:
>
>I'm willing to bet that the number of times people will type "fossil
> mv/rm X Y" and not actually want to mv/rm X to Y just afterwards is
> vanishingly small. More to the point; let's reverse your "-s"-flag; I.e.:
>
>$ fossil mv X Y
As I understand it, fossil currently deletes one file from disk when doing
and update if this file has been removed by another user.
For me, it is incoherent that fossil does not do the same on commit. Of
course, only for the case that there is a copy of the file in the previous
version and tha
Le 2012-12-12 06:28, Ramon Ribó a écrit :
As I understand it, fossil currently deletes one file from disk when
doing and update if this file has been removed by another user.
For me, it is incoherent that fossil does not do the same on commit.
Of course, only for the case that there is a c
On Wed, Dec 12, 2012 at 08:28:55AM -0500, Martin Gagnon wrote:
> Le 2012-12-12 06:28, Ramon Ribó a écrit :
> >
> > As I understand it, fossil currently deletes one file from disk when
> >doing and update if this file has been removed by another user.
> >
> > For me, it is incoherent that fossil
Chad Perrin decía, en el mensaje "Re: [fossil-users] why does `fossil rm' not
do the "real" thing?" del Miércoles, 12 de Diciembre de 2012 18:22:53:
> I rather suspect that, if Fossil continues to grow in usage over time,
> and if it fails to implement sane defaults
On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler wrote:
> If that happens, please make sure to include "git" in the new name. That's
> what all the naysayers are trying to convert Fossil into, anyway.
+1 :)
___
fossil-users mailing list
fossil-users@lists.
On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote:
> On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler wrote:
> > If that happens, please make sure to include "git" in the new name. That's
> > what all the naysayers are trying to convert Fossil into, anyway.
>
> +1 :)
Screw that. Git
On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin wrote:
> Screw that. Git makes exactly the kind of UI mistakes I'm talking about
> eliminating.
Well, one thing that I don't know whether to call "UI mistake", but it
is certainly an inconvenience, is that to obtain accurate status
information (simi
On Wed, Dec 12, 2012 at 3:13 PM, Chad Perrin wrote:
> On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote:
>> On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler wrote:
>> > If that happens, please make sure to include "git" in the new name. That's
>> > what all the naysayers are trying to
If we're talking about adding "git" to the name because of this whole
"rm" thing, we might as well consider "mercurial" as a candidate too.
Mercurial behaves sensibly and removes the file automatically on rm.
Naysayers aren't trying to make Fossil Git, we're just trying to make it
do what most
Nolan Darilek decía, en el mensaje "Re: [fossil-users] why does `fossil rm'
not do the "real" thing?" del Miércoles, 12 de Diciembre de 2012 22:38:16:
> Naysayers aren't trying to make Fossil Git, we're just trying to make it
> do what most other VCSs
On 12/12/2012 08:42 PM, Richie Adler wrote:
What's next? Replacing SQLite with individual files?
Absolutely not, and statements like this do more harm than good because
they willfully disregard the point of what is being expressed. The point
is not to be alarmist and extreme, as statements l
On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler
wrote:
> Sorry, I still think that the intention is to destroy what Fossil has
> of unique to offer to be able to say that Git or Mercurial it's the
> same and they should be preferred to Fossil.
>
> What's next? Replacing SQLite with individual fi
Nolan Darilek writes:
> If we're talking about adding "git" to the name because of this whole
> "rm" thing, we might as well consider "mercurial" as a candidate
> too. Mercurial behaves sensibly and removes the file automatically on
> rm. Naysayers aren't trying to make Fossil Git, we're just try
On Thu, 13 Dec 2012 06:49:08 -0300
Richie Adler wrote:
> Can you please killfile me and leave me alone?
That's not the point 'cause your comments are not polite and
disturbing to other Fossil users as you can see...
Sincerely,
Gour
--
A person is said to be elevated in yoga when, having re
On Thu, 13 Dec 2012 08:16:48 +0100, Gour wrote:
On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler
wrote:
Sorry, I still think that the intention is to destroy what Fossil has
of unique to offer to be able to say that Git or Mercurial it's the
same and they should be preferred to Fossil.
What'
On Thu, 13 Dec 2012 10:58:29 +0100, Gour wrote:
On Thu, 13 Dec 2012 06:49:08 -0300
Richie Adler wrote:
Can you please killfile me and leave me alone?
That's not the point 'cause your comments are not polite and
disturbing to other Fossil users as you can see...
+1
Sincerely,
Gour
On 12/12/12, Themba Fletcher wrote:
> to alias 'fossil rm' to 'fossil rm -f'.
That is a disaster waiting to happen. If the user in question forgets
that they've done that, and then runs a series of commands from
someone who *didn't* do that (either cut-n-paste from an answer on the
list or the we
On 12/13/12 05:07, Carson Chittom wrote:
> Nolan Darilek writes:
>
>> If we're talking about adding "git" to the name because of this whole
>> "rm" thing, we might as well consider "mercurial" as a candidate
>> too. Mercurial behaves sensibly and removes the file automatically on
>> rm. Naysayers
On 12/13/12 00:51, Themba Fletcher wrote:
> I'd like to return to what I think should be the focus, which is
> discussing what the "right thing" is for fossil to do. As a possible
> compromise, the combination of a '-f' flag to fossil rm with the
> ability to add aliases (mentioned as a possible fe
On Thu, 13 Dec 2012 14:09:46 +0100, Jan Danielsson
wrote:
On 12/13/12 05:07, Carson Chittom wrote:
Nolan Darilek writes:
If we're talking about adding "git" to the name because of this whole
"rm" thing, we might as well consider "mercurial" as a candidate
too. Mercurial behaves sensibly a
On 12/13/12 05:01, Themba Fletcher wrote:
>>> What's next? Replacing SQLite with individual files?
>>
>> Absolutely not, and statements like this do more harm than good because they
>> willfully disregard the point of what is being expressed. The point is not
>> to be alarmist and extreme, as state
2012/12/13 Jan Danielsson
> "Richie Adler" (that is, myself, not Themba Fletcher) wrote:
> >>> What's next? Replacing SQLite with individual files?
> >>
> >> Absolutely not, and statements like this do more harm than good because
> they
> >> willfully disregard the point of what is being expresse
On 12/13/2012 08:40 AM, Marcelo wrote:
They want the good things about fossil but they want to keep working
as if it were Git. I say, if they like Git so much, eat the crow that
comes with it.
And that doesn't even make sense, either. If I wanted Git, then I'd use
Git, full stop. It's sil
On Thu, 13 Dec 2012 08:54:25 -0600
Nolan Darilek wrote:
> Making this sort of argument damages the cause because it puts those
> of us advocating for a thing in a position we aren't necessarily in,
> so it makes us want to just let the point go.
Fortunately, Richard is mature person...
Since
FWIW, I am following this thread with great interest. I think I understand
the various points of view. I think most everybody brings up good points,
and I encourage this kind of discussion.
My current leanings are to change "rm" and "mv" as follows:
(1) "fossil rm xyx.txt" will remove the file
On Thu, 13 Dec 2012 10:38:36 -0500
Richard Hipp wrote:
> (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and
> only if an exact copy of xyz.txt exists under control. If xyz.txt
> has been modified or if xyz.txt has never been checked in (and the
> "fossil rm" is simply to rever
> (1) "fossil rm xyx.txt" will remove the file xyz.txt from disk if and only
> if an exact copy of xyz.txt exists under control. If xyz.txt has been
> modified or if xyz.txt has never been checked in (and the "fossil rm" is
> simply to reverse a prior "fossil add") then xyz.txt is unchanged. Eith
2012/12/13 Nolan Darilek
> On 12/13/2012 08:40 AM, Marcelo wrote:
>
>> They want the good things about fossil but they want to keep working as
>> if it were Git. I say, if they like Git so much, eat the crow that comes
>> with it.
>>
>> And that doesn't even make sense, either. If I wanted Git, t
On 12/13/2012 11:02 AM, Marcelo wrote:
You may laugh at the image of the cackling, moustache twirling villain
-- after all, I've used the image myself in hyperbole. But what you're
deliberate neglecting is that rebase *has been requested already*,
even when it goes against all what Fossil stand
On Thu, 13 Dec 2012 18:02:25 +0100, Marcelo wrote:
2012/12/13 Nolan Darilek
On 12/13/2012 08:40 AM, Marcelo wrote:
They want the good things about fossil but they want to keep working as
if it were Git. I say, if they like Git so much, eat the crow that
comes
with it.
And that doesn't
On Thu, Dec 13, 2012 at 6:13 PM, Nolan Darilek wrote:
> You don't get to reframe this discussion by
> putting everyone who asks for a change in the same category. Sorry, I won't
> let you do that. Me asking for rm behavior today does not mean I'll ask for
> rebase tomorrow, nor does it mean that
/13/12 09:08 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] why does `fossil rm' not do the "real" thing?
FWIW, I am following this thread with great interest. I think I understand the
various points of view. I think most everybody brings up good points, a
On 12/13/2012 07:38 AM, Richard Hipp wrote:
> FWIW, I am following this thread with great interest. I think I
> understand the various points of view. I think most everybody brings
> up good points, and I encourage this kind of discussion.
>
> My current leanings are to change "rm" and "mv" as f
On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" wrote:
> In order to continue the debate:
> In my work flow, I do rm or mv in file system as and when needed. I do
> fossil rm or fossil mv only when reviewing my changes before commit.
Well, yes, that is the way I do it too. I suspect that there
On Thu, Dec 13, 2012 at 6:08 PM, Eric wrote:
> On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"
> wrote:
> > In order to continue the debate:
> > In my work flow, I do rm or mv in file system as and when needed. I do
> > fossil rm or fossil mv only when reviewing my changes before commit.
>
>
On Fri, 14 Dec 2012 00:08:04 +0100, Eric wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"
wrote:
In order to continue the debate:
In my work flow, I do rm or mv in file system as and when needed. I do
fossil rm or fossil mv only when reviewing my changes before commit.
Well, yes,
* Richard Hipp [20121213 16:37]:
> My current leanings are to change "rm" and "mv" as follows:
[...]
> It seems to me that the behaviors above are the most "intuitive" and
> provide developers with the least amount of surprise.
I agree.
Regarding your later post, I fail to see how this prop
On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp wrote:
On Thu, Dec 13, 2012 at 6:08 PM, Eric wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"
wrote:
> In order to continue the debate:
> In my work flow, I do rm or mv in file system as and when needed. I
do
> fossil rm or fossil
Who would have guessed that something as simple as having rm remove the
file from disk would prompt opponents to:
* claim that I want Fossil to be like Git.
* Call me "lazy."
* Insult my intelligence by claiming that I don't know what a VCS is
or should do.
Done with this thread. Keep it c
On Thu, Dec 13, 2012 at 4:48 PM, j. v. d. hoff wrote:
> On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp wrote:
>
> On Thu, Dec 13, 2012 at 6:08 PM, Eric wrote:
>>
>> On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"
>>> wrote:
>>> > In order to continue the debate:
>>> > In my work flow, I d
> Well, yes, that is the way I do it too. I suspect that there are some
> who do not review their changes before commit, and that many of those
> commit way too often, essentially treating their VCS as a backup method.
> This of course leads to junk, non-functional checkins, followed by an
> unheal
On 12/14/12 00:23, Richard Hipp wrote:
> But, should there be an opt-in option to also make the disk changes?
Yes -- definitely.
--
Kind regards,
Jan Danielsson
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm
On 12/14/12 00:56, Nolan Darilek wrote:
> Who would have guessed that something as simple as having rm remove the
> file from disk would prompt opponents to:
>
> * claim that I want Fossil to be like Git.
> * Call me "lazy."
> * Insult my intelligence by claiming that I don't know what a VCS is
On Fri, 14 Dec 2012 10:55:50 +0100
Jan Danielsson
wrote:
>I must say, I'm not quite as fond of the fossil community as I once
> was. I have no interest in being insulted further.
That's pity that immature people are chasing away older members. :-(
Sincerely,
Gour
--
Thus the wise living
On Fri, Dec 14, 2012 at 12:23 AM, Richard Hipp wrote:
> So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty
> much convinced me at this point to keep the current behavior of "fossil rm"
> and "fossil mv".
I'm happy to read this. Thank you.
I had refrained to chime in the di
Richard Hipp wrote:
[...]
> But, should there be an opt-in option to also make the disk changes?
> Perhaps "fossil rm abc.txt" just removes abc.txt from configuration
> management, but "fossil rm -f abc.txt" also removes it from disk?
Yes, please. (Particularly with fossil mv; refactoring large n
On Thu, Dec 13, 2012 at 11:08:04PM +, Eric wrote:
> On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" wrote:
> > In order to continue the debate:
> > In my work flow, I do rm or mv in file system as and when needed. I do
> > fossil rm or fossil mv only when reviewing my changes before commit.
On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
>
> This is the classical divide between pragmatists (I want to get my job with
> with minimal pain so I can go home a play ball with my son) versus the
> idealists (source code management means doing x, y and z and no more and no
> les
Here's a thought:
Let's remove the rm alias and make it just "fossil remove". That will
eliminate all my objections.
When I issue a "rm", whether at my shell, or in hg, git, svn, everywhere
else but CVS apparently, which is the reason for establishing this
expectation, it behaves a certain w
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin wrote:
> On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
> >
> > This is the classical divide between pragmatists (I want to get my job
> with
> > with minimal pain so I can go home a play ball with my son) versus the
> > idealists (sour
Le 2012-12-14 12:50, Matt Welland a écrit :
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin mailto:c...@apotheon.net>> wrote:
On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
>
> This is the classical divide between pragmatists (I want to get
my job with
> with
On Fri, 14 Dec 2012 10:10:44 -0700, Chad Perrin wrote:
Well, I had to pick one message to answer
Aaargh! (there should be more "a"s)
1) Telling the operating system to delete a file from disk and telling
the VCS that a file which is in the parent commit s
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 all about.
>
> 5) SCM stands for Software Configuration Management which is not the
>
On Sat, Dec 15, 2012 at 12:06:02AM +, Eric wrote:
>
> 1) Telling the operating system to delete a file from disk and telling
> the VCS that a file which is in the parent commit should not be in the
> next are two very different actions and I think they should be kept
> separate.
I'm perfectly
On Fri, Dec 14, 2012 at 08:46:22PM -0700, Chad Perrin wrote:
> On Sat, Dec 15, 2012 at 12:06:02AM +, Eric wrote:
> >
> > 1) Telling the operating system to delete a file from disk and telling
> > the VCS that a file which is in the parent commit should not be in the
> > next are two very diffe
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.
Whether the current behavior being "ideal" or not is an entirely di
On Fri, 14 Dec 2012 20:26:33 -0800
"Joe Mistachkin" 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 in
order to evolve
On Sat, 15 Dec 2012 05:26:33 +0100, 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
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 w
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 Mista
On Sat, 15 Dec 2012 10:56:20 +0100, Joe Mistachkin
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 to mind. I can tell you
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
On Sat, 15 Dec 2012 12:03:26 +0100, 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 Fossil no
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 specu
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
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 explanation is:
darcs obliter
On Sat, 15 Dec 2012 01:52:11 +0100, Jan Danielsson
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 all about.
>>
>> 5)
On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin 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 did say "Well, I h
On Sat, Dec 15, 2012 at 05:15:17PM +, Eric wrote:
> On Fri, 14 Dec 2012 20:46:22 -0700, Chad Perrin 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
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 relie
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 behavi
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
> activ
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
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-top
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,
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 t
Disclaimer:
1) I care nothing about backward compatibility.
2) I only care about the efficiency of tools that I use to help me do my job.
On Dec 15, 2012, at 11:02 PM, Jan Danielsson wrote:
> On 12/16/12 03:28, Joe Mistachkin wrote:
> Still, I think I'm right. I don't think any of the issues
On Sat, Dec 15, 2012 at 03:36:43PM -0800, Joe Mistachkin wrote:
> 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 rea
On Sun, Dec 16, 2012 at 11:06:57AM -0500, daniel gregory wrote:
>
> I think we should write a patch… publish is and see how many people
> actually use the patched version instead of the real version… then we'd
> have an argument against the conservatives that just don't like change.
That's not a
On Sat, Dec 15, 2012 at 06:28:52PM -0800, 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 argu
Chad Perrin wrote:
>
> If you use bleeding edge versions, you should already be prepared to deal
> with changes in behavior. I don't see the problem.
>
I help write the "bleeding edge" versions. Therefore, it is useful that I
run them on a daily basis as well.
>
> There will always be someone
Chad Perrin wrote:
>
> zsh: sports metaphor not found
>
Sorry, I was attempting to inject some humor into this discussion because
it has grown very tedious.
>
> HDDs also suffer wear and tear during I/O operations, and new SSDs easily
> last long enough that, relative to HDDs, this should no l
1 - 100 of 104 matches
Mail list logo
