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
Hi there,
there is another thread happening which is suggesting or proposing a
future version of fossil rm which is not identical to the current one.
What is the specific desired future behaviour?
I think there are three possible future commands to be considered --
whether implemented as
On Fri, Dec 14, 2012 at 07:58:03PM +, Francis Daly wrote:
Hi there,
I forgot at least one case, which I can shoe-horn in here by adding:
what would be different if rm a were added just before fossil
new-rm a, as in:
echo X a; echo X b; echo X c;
fossil add a b
fossil commit -m a and b =
Hi,
I'd like to move some projects from Github to self-hosted fossil (or maybe
chisel, I haven't decided yet). However, I'd like to keep the Github
repository available and updated.
I can do a one-time move with fast-export/fast-import, but that doesn't
help for new code. I'm willing to have
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
Hello,
It seems that some of those who are opposed to changing the behavior
of rm/mv are reaching a consensus that the names rm and mv were
poorly chosen, because they have a Unix connotation, and rename and
move has been suggested instead. So -- is there any reason we can't
have both?
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 Fri, Dec 14, 2012 at 7:20 PM, Jan Danielsson
jan.m.daniels...@gmail.comwrote:
Hello,
It seems that some of those who are opposed to changing the behavior
of rm/mv are reaching a consensus that the names rm and mv were
poorly chosen, because they have a Unix connotation, and rename and
On Fri, Dec 14, 2012 at 5:29 PM, Richard Hipp d...@sqlite.org wrote:
On Fri, Dec 14, 2012 at 7:20 PM, Jan Danielsson jan.m.daniels...@gmail.com
wrote:
Hello,
It seems that some of those who are opposed to changing the behavior
of rm/mv are reaching a consensus that the names rm and mv
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 status messages emitted by fossil (I think on
merge?) and it's pretty
Reposted from fossil-dev:
OLD: http://www2.sqlite.org/src/ci/52e755943f?sbs=1#chunk1
NEW: http://www.sqlite.org/src/ci/52e755943f?sbs=1#chunk1
OLD:
http://www2.fossil-scm.org/fossil/fdiff?v1=955cc67ace8fb622v2=e2e1c87b86664b45#chunk24
NEW:
On 12/15/12 03:15, Richard Hipp wrote:
[---]
It is suggested to me (off-list) that it would be too disruptive to
abruptly change the meaning of fossil rm to start deleting from disk. So
I propose a staged implementation:
Stage 1:
(a) fossil rm -f deletes from disk (if it is safe to do so)
On 12/14/2012 06:15 PM, Richard Hipp wrote:
On Fri, Dec 14, 2012 at 8:58 PM, Themba Fletcher
themba.fletc...@gmail.com mailto:themba.fletc...@gmail.com wrote:
Could I humbly suggest unmanage for the name of the
remove-from-repo-and-leave-the-disk-alone command? This would be
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 Sat, Dec 15, 2012 at 03:44:28AM +0100, Jan Danielsson wrote:
On 12/15/12 03:15, Richard Hipp wrote:
[---]
It is suggested to me (off-list) that it would be too disruptive to
abruptly change the meaning of fossil rm to start deleting from disk. So
I propose a staged implementation:
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
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
vertical gray line behind the diff content.
This will fix that, if you'd like to have
27 matches
Mail list logo
