On Sun, Dec 16, 2012 at 05:13:24PM -0800, Joe Mistachkin wrote:
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.
I guess you didn't find my rejoinder amusing.
HDDs also
On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote:
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
Do you two need a room? If so, there's a local so-called love hotel I
can book for you in two-hour slots.
On 18 December 2012 13:00, Chad Perrin c...@apotheon.net wrote:
On Sun, Dec 16, 2012 at 05:02:23PM -0800, Joe Mistachkin wrote:
Chad Perrin wrote:
If you use bleeding edge
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 jan.m.daniels...@gmail.com wrote:
On 12/16/12 03:28, Joe Mistachkin wrote:
Still, I think I'm right. I
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 reasonable
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 bad
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 argument.
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 longer
I don't really care which behavior is the default. I've dealt with
both long enough that neither is surprising, and my workflow doesn't
change enough to notice for this. I'm just tired of seeing the bogus
claim that one is somehow surprising and natural and one isn't.
The only thing I want to
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
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, 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
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
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
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 or
On Fri, 14 Dec 2012 10:55:50 +0100
Jan Danielsson
jan.m.daniels...@gmail.com 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
On Fri, Dec 14, 2012 at 12:23 AM, Richard Hipp d...@sqlite.org 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
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 numbers
On Thu, Dec 13, 2012 at 11:08:04PM +, Eric wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com 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
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
less
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 way.
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin 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 minimal pain so I can go home a play ball with my son) versus the
Le 2012-12-14 12:50, Matt Welland a écrit :
On Fri, Dec 14, 2012 at 10:32 AM, Chad Perrin c...@apotheon.net
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
On Fri, 14 Dec 2012 10:10:44 -0700, Chad Perrin c...@apotheon.net wrote:
Well, I had to pick one message to answer
Aaargh! (there should be more as)
1) Telling the operating system to delete a file from disk and telling
the VCS that a file which is in the
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
same
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 different
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
On Thu, 13 Dec 2012 08:16:48 +0100, Gour g...@atmarama.net wrote:
On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler richiead...@gmail.com
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
On Thu, 13 Dec 2012 10:58:29 +0100, Gour g...@atmarama.net wrote:
On Thu, 13 Dec 2012 06:49:08 -0300
Richie Adler richiead...@gmail.com 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
On 12/12/12, Themba Fletcher themba.fletc...@gmail.com 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
On Thu, 13 Dec 2012 14:09:46 +0100, Jan Danielsson
jan.m.daniels...@gmail.com wrote:
On 12/13/12 05:07, Carson Chittom wrote:
Nolan Darilek no...@thewordnerd.info 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
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 statements like
2012/12/13 Jan Danielsson jan.m.daniels...@gmail.com
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
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
On Thu, 13 Dec 2012 08:54:25 -0600
Nolan Darilek no...@thewordnerd.info 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
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 d...@sqlite.org 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
(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. Either
way,
2012/12/13 Nolan Darilek no...@thewordnerd.info
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
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
On Thu, 13 Dec 2012 18:02:25 +0100, Marcelo richiead...@gmail.com wrote:
2012/12/13 Nolan Darilek no...@thewordnerd.info
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
On Thu, Dec 13, 2012 at 6:13 PM, Nolan Darilek no...@thewordnerd.info 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
/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, and I
encourage this kind
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 follows:
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com 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
On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com
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
On Fri, 14 Dec 2012 00:08:04 +0100, Eric e...@deptj.eu wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com
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
* Richard Hipp d...@sqlite.org [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
On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp d...@sqlite.org wrote:
On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com
wrote:
In order to continue the debate:
In my work flow, I do rm or mv in file system as and
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
On Thu, Dec 13, 2012 at 4:48 PM, j. v. d. hoff veedeeh...@googlemail.comwrote:
On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp d...@sqlite.org wrote:
On Thu, Dec 13, 2012 at 6:08 PM, Eric e...@deptj.eu wrote:
On Thu, 13 Dec 2012 12:55:55 -0500, Altu Faltu altufa...@mail.com
wrote:
In
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
unhealthy
On Wed, Dec 12, 2012 at 1:24 AM, Jan Danielsson
jan.m.daniels...@gmail.comwrote:
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.:
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
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
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 and options like what you just
On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com 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
On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote:
On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com 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 :)
On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin c...@apotheon.net 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
On Wed, Dec 12, 2012 at 3:13 PM, Chad Perrin c...@apotheon.net 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 richiead...@gmail.com wrote:
If that happens, please make sure to include git in the new name. That's
what all
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 other
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
On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler richiead...@gmail.com
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
Nolan Darilek no...@thewordnerd.info 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,
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 no...@thewordnerd.info wrote:
Weighing in on this, finally:
It's interesting to me that everyone speculates that this *might* break
things for some
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 k...@lightpowered.org 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
On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher
themba.fletc...@gmail.com 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 no...@thewordnerd.info
wrote:
Weighing in on this, finally:
It's
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.
I
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
seems. --
On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin c...@apotheon.net 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
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
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
On Tue, Nov 20, 2012 at 8:32 AM, j. van den hoff
veedeeh...@googlemail.comwrote:
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
On Tue, 20 Nov 2012 15:00:29 +0100, Remigiusz Modrzejewski
l...@maxnet.org.pl 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
On Tue, Nov 20, 2012 at 6:45 AM, Richard Hipp d...@sqlite.org 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,
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 ja...@calminferno.net
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
98 matches
Mail list logo
