On Tue, Feb 28, 2012 at 07:28:11AM -0500, Richard Hipp wrote:
I'm leaning more toward Fossil 2.0 that has a number of incompatible
changes to the command-line interface, such as having fossil rm and
fossil mv actually delete and rename the files. To be clear, the
repository file format and
On Mon, Mar 5, 2012 at 6:03 PM, Christopher Berardi cbera...@natoufa.comwrote:
(n+2) Have a compile-time configuration option to choose what to
build into fossil. For example, maybe I just want the 'core'
vcs without the wiki, ui, or bug-tracking. Or, maybe I just
On Mon, Mar 05, 2012 at 06:12:15PM -0500, Richard Hipp wrote:
On Mon, Mar 5, 2012 at 6:03 PM, Christopher Berardi cbera...@natoufa.com
wrote:
(n+2) Have a compile-time configuration option to choose what to
build into fossil. For example, maybe I just want the
On Mon, 5 Mar 2012 18:12:15 -0500
Richard Hipp d...@sqlite.org wrote:
On Mon, Mar 5, 2012 at 6:03 PM, Christopher Berardi
cbera...@natoufa.comwrote:
(n+2) Have a compile-time configuration option to choose what to
build into fossil. For example, maybe I just want the 'core'
On Tue, 28 Feb 2012 18:03:55 -0500
Christopher Berardi cbera...@natoufa.com
wrote:
Why not just use your shell's aliasing mechanism? For example, in a
Bourne compatible shell you could place this in your .shrc file:
alias cip='fossil ci --private'
You're right. It's possible to do it via
On Tue, Feb 28, 2012 at 07:28, Richard Hipp d...@sqlite.org wrote:
Assuming we go with Fossil 2.0, can somebody propose a list of interface
changes that are needed. We don't want to repeat this exercise if it can be
avoided, so let's fix everything all at once. Here's a start:
(1) fossil
Leo, did you know you can type 'fossil time' from the cmd line to get the
last 10 commits? then just use the first 3-6 characters to reference the
correct parent, that way avoiding the command line.
I'm not saying that it solves the 'single command' problem, but it sure
beats launching the ui
On Wed, Feb 29, 2012 at 13:00, Tomek Kott tkott.s...@gmail.com wrote:
Leo, did you know you can type 'fossil time' from the cmd line to get the
last 10 commits? then just use the first 3-6 characters to reference the
correct parent, that way avoiding the command line.
How can I do it in a
On Wed, Feb 29, 2012 at 7:59 PM, Leo Razoumov slonik...@gmail.com wrote:
How can I do it in a script? Referencing a parent is a fundamental DAG
operation and it is missing from fossil 1.x. I hope fossil 2.0 will
have something to address it.
stephan@tiny:~/cvs/fossil/fossil$ f json timeline
I haven't spent any time with the JSON API, but, a very quick thought:
It's possible for a check-in to have more than one parent. I assume you model
that.
Would it be worth while to change parentUuid to parents for the sake of
consistency
with the tags attribute?
-B
On Wednesday, February
On Wed, Feb 29, 2012 at 8:56 PM, Brian Smith br...@linuxfood.net wrote:
I haven't spent any time with the JSON API, but, a very quick thought:
It's possible for a check-in to have more than one parent. I assume you
model that.
Actually... you've discovered a huge oversight.
Would it be
On Wednesday, February 29, 2012 at 12:01 PM, Stephan Beal wrote:
On Wed, Feb 29, 2012 at 8:56 PM, Brian Smith br...@linuxfood.net
(mailto:br...@linuxfood.net) wrote:
I haven't spent any time with the JSON API, but, a very quick thought:
It's possible for a check-in to have more than one
On Wed, Feb 29, 2012 at 9:23 PM, Brian Smith br...@linuxfood.net wrote:
I think the only appropriate response is Oh snap.
Indeed! How does this look:
stephan@tiny:~/cvs/fossil/fossil/src$ f json timeline ci -n 1 -I 2
{
...
payload:{
limit:1,
timeline:[{
type:checkin,
On Wed, Feb 29, 2012 at 10:20 PM, Stephan Beal sgb...@googlemail.comwrote:
On Wed, Feb 29, 2012 at 9:23 PM, Brian Smith br...@linuxfood.net wrote:
I think the only appropriate response is Oh snap.
Indeed! How does this look:
i got tired of waiting ;) and went ahead with:
a) removed
You read my mind. :)
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Wednesday, February 29, 2012 at 1:47 PM, Stephan Beal wrote:
On Wed, Feb 29, 2012 at 10:20 PM, Stephan Beal sgb...@googlemail.com
(mailto:sgb...@googlemail.com) wrote:
On Wed, Feb 29, 2012 at 9:23 PM, Brian
On Wed, Feb 29, 2012 at 16:47, Stephan Beal sgb...@googlemail.com wrote:
Indeed! How does this look:
i got tired of waiting ;) and went ahead with:
a) removed parentUuid
b) defined the first element in the parents array to be the primary
parent.
Thanks for your effort! Time permitting I
(n+1): As mentioned in some of my earlier posts (see [1]), I would be
great to have an ability to {commit | diff | maybe other file related
commands} using ranges like 'fossil commit --range 1,3-4' where
numbers correspond to the file order as presented by 'fossil chan'.
This is more like feature
On Tue, Feb 28, 2012 at 2:06 AM, Gour g...@atmarama.net wrote:
On Wed, 21 Dec 2011 12:25:19 -0500
Richard Hipp d...@sqlite.org wrote:
I fear to change it now, though, since it might really mess up people
who are used to the older style.
What about having something like:
fossil rm
On Tue, 28 Feb 2012 07:28:11 -0500
Richard Hipp d...@sqlite.org wrote:
Assuming we go with Fossil 2.0, can somebody propose a list of
interface changes that are needed. We don't want to repeat this
exercise if it can be avoided, so let's fix everything all at once.
Here's a start:
(1)
(1) fossil rm removes the files from the disk
(2) fossil mv renames the files on disk
(3) fossil settings crnl-glob **
(4) fossil update == fossil update current
(5) Unlimited undo (purgin old undos after a defined number of days)
(6) Explain in more detail the clock problems with the
On Tue, Feb 28, 2012 at 07:59, Ramon Ribó ram...@compassis.com wrote:
(1) fossil rm removes the files from the disk
(2) fossil mv renames the files on disk
(3) fossil settings crnl-glob **
(4) fossil update == fossil update current
(5) Unlimited undo (purgin old undos after a defined
On Tue, 28 Feb 2012 08:22:52 -0500
Leo Razoumov slonik...@gmail.com wrote:
(8) search through wiki pages, timeline, tickets (fossil-scm.org
branch exp-search [1] can be a good start)
Thank you for this one which I forgot to mention.
Sincerely,
Gour
--
Bewildered by the modes of material
On Tue, 28 Feb 2012 08:22:52 -0500
Leo Razoumov slonik...@gmail.com wrote:
(1) fossil rm removes the files from the disk
(2) fossil mv renames the files on disk
(3) fossil settings crnl-glob **
(4) fossil update == fossil update current
(5) Unlimited undo (purgin old undos after
(1) fossil rm removes the files from the disk
(2) fossil mv renames the files on disk
(3) fossil settings crnl-glob **
(4) fossil update == fossil update current
(5) Unlimited undo (purgin old undos after a defined number of days)
(6) Explain in more detail the clock problems with the
(1) fossil rm removes the files from the disk (2) fossil mv renames
the files on disk (3) fossil settings crnl-glob ** (4) fossil
update == fossil update current (5) Unlimited undo (purgin old undos
after a defined number of days) (6) Explain in more detail the clock
problems with
On Tue, Feb 28, 2012 at 08:22, Leo Razoumov slonik...@gmail.com wrote:
On Tue, Feb 28, 2012 at 07:59, Ramon Ribó ram...@compassis.com wrote:
(1) fossil rm removes the files from the disk
(2) fossil mv renames the files on disk
(3) fossil settings crnl-glob **
(4) fossil update == fossil
On Tue, 28 Feb 2012 14:47:00 +0100
Ramon Ribó ram...@compassis.com wrote:
[...]
(9) in the web page, possibility to mark branches as hidden. It will
be invisible in the timeline, branches section and files section
(files belonging only to hidden branches do not appear), unless a
special
In fact, the most annoying thing is to go to the files section and
find there files of several years ago that are not used anymore, or
that come from a mistake and they will remain there for years and
years more, making more difficult to review the other files.
The possibility of seeing only the
On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
c) some aliasing mechanism so that user can create aliases for commands
invoked with common options, e.g, ability to define
cip = ci --private
Why not just use your shell's aliasing mechanism? For example, in a
Bourne compatible shell
On 2/28/2012 3:03 PM, Christopher Berardi wrote:
On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
c) some aliasing mechanism so that user can create aliases for commands
invoked with common options, e.g, ability to define
cip = ci --private
Why not just use your shell's aliasing
At 03:04 PM 2/28/2012, Andreas Kupries wrote:
On 2/28/2012 3:03 PM, Christopher Berardi wrote:
On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
c) some aliasing mechanism so that user can create aliases
for commands
invoked with common options, e.g, ability to define
cip = ci --private
On Tue, Feb 28, 2012 at 03:04:22PM -0800, Andreas Kupries wrote:
On 2/28/2012 3:03 PM, Christopher Berardi wrote:
On Tue, Feb 28, 2012 at 01:51:29PM +0100, Gour wrote:
c) some aliasing mechanism so that user can create aliases for commands
invoked with common options, e.g, ability to define
Not everyone uses Unix.
Are there Windows shells supporting aliases, outside of 'mingw/bash' ?
It's not free but I find JP Software's Take Command (TCMD) and Take
Command Console (TCC) indispensable. http://jpsoft.com
--
___
fossil-users mailing list
On Wed, 21 Dec 2011 12:25:19 -0500
Richard Hipp d...@sqlite.org wrote:
I fear to change it now, though, since it might really mess up people
who are used to the older style.
What about having something like:
fossil rm --force|-f FILE1 FILE2 ...
where using '--force' option would make Fossil
Hijacking the summary votes:
+1 modifying rm/mv to actually rm/mv files in file system *only with -f*
-1 renaming rm to untrack or something similar that conveys correct
message -- personally I think of fossil rm as acting on the repository.
So I am, in fact, removing the file from the
On Thu, 22 Dec 2011 10:06:47 -0500
Tomek Kott tkott.s...@gmail.com wrote:
-1 renaming rm to untrack or something similar that conveys
correct message -- personally I think of fossil rm as acting on the
repository. So I am, in fact, removing the file from the repository.
Except you're not
I'm using fossil for the first time, on a new project -- it hurts how
pragmatic and elegant fossil is, I had to try it. Over the years, I've
developed some habits from hg and git that I can't seems to reconcile
with how fossil does things. Can somebody tell me what I'm missing or
how my workflow
people can have it the right way?
Jeremy
From: Richard Hipp
Sent: Wednesday, December 21, 2011 12:25 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra
$ fossil rm file1
DELETED file1
$ ls
file1
$ rm file1
Is there a reason behind
On Wed, 21 Dec 2011 12:30:16 -0500 Jeremy Cowgar wrote:
I’m in the same boat, doing two actions for every one in other SCM
systems, however I do not do it dozens of times a day, so I’ve always
just done it with a little gnashing of the teeth.
If we're having a vote, +1. I'd like it if rm and
On Wed, 2011-12-21 at 12:25 -0500, Richard Hipp wrote:
On Wed, Dec 21, 2011 at 12:08 PM, Nick Zalutskiy pace...@gmail.com
wrote:
I'm using fossil for the first time, on a new project -- it
hurts how
pragmatic and elegant fossil is, I had to try it. Over the
+1 for fossil doing my file handling ;)
+1 for an option to retain old CVS behavior.
On Wed, Dec 21, 2011 at 1:02 PM, Ramon Ribó ram...@compassis.com wrote:
In my opinion, this option should be changed without fear. If fossil
is ready to delete the files when doing an update, why not delete
On Wed, December 21, 2011 5:41 pm, Dmitry Chestnykh wrote:
On Wed, 21 Dec 2011 12:30:16 -0500 Jeremy Cowgar wrote:
Iâ..m in the same boat, doing two actions for every one in other SCM
systems, however I do not do it dozens of times a day, so Iâ..ve always
just done it with a little gnashing
It is not the job of the SCM system to keep in step with my working
directory
Why not? In that case, fossil update shouldn't delete files that
have been removed from repository, but it does.
Another issue is that an SCM system is _not_ a backup tool, but many
people seem to think that it is.
On Wed, Dec 21, 2011 at 06:41:54PM +0100, Dmitry Chestnykh wrote:
On Wed, 21 Dec 2011 12:30:16 -0500 Jeremy Cowgar wrote:
I’m in the same boat, doing two actions for every one in other SCM
systems, however I do not do it dozens of times a day, so I’ve always
just done it with a little
On Wed, 21 Dec 2011 20:21:18 +0100
Ramon Ribó ram...@compassis.com wrote:
It is not the job of the SCM system to keep in step with my working
directory
Why not? In that case, fossil update shouldn't delete files that
have been removed from repository, but it does.
Any chance of getting
On Wed, 21 Dec 2011 18:51:33 - Eric wrote:
On Wed, December 21, 2011 5:41 pm, Dmitry Chestnykh wrote:
If we're having a vote, +1. I'd like it if rm and mv actually
deleted and renamed files.
It is not the job of the SCM system to keep in step with my working
directory, it is its job
@lists.fossil-scm.org
Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra
Fossil have commands to manage your working tree, like
checkout/revert/undo/redo/stash/merge. They do things to files in
directories. rm/mv are inconsistent with this behavior
On Wed, December 21, 2011 7:21 pm, Ramon Ribó wrote:
It is not the job of the SCM system to keep in step with my working
directory
Why not? In that case, fossil update shouldn't delete files that
have been removed from repository, but it does.
Another issue is that an SCM system is _not_ a
On Wed, December 21, 2011 7:31 pm, Mike Meyer wrote:
On Wed, 21 Dec 2011 20:21:18 +0100
Ramon Ribó ram...@compassis.com wrote:
It is not the job of the SCM system to keep in step with my working
directory
Why not? In that case, fossil update shouldn't delete files that
have been removed
On Wed, 21 Dec 2011 19:44:50 -
Eric e...@deptj.eu wrote:
On Wed, December 21, 2011 7:31 pm, Mike Meyer wrote:
On Wed, 21 Dec 2011 20:21:18 +0100
Ramon Ribó ram...@compassis.com wrote:
Another issue is that an SCM system is _not_ a backup tool, but
many people seem to think that it
On Wed, 2011-12-21 at 18:41 +0100, Dmitry Chestnykh wrote:
On Wed, 21 Dec 2011 12:30:16 -0500 Jeremy Cowgar wrote:
I’m in the same boat, doing two actions for every one in other SCM
systems, however I do not do it dozens of times a day, so I’ve always
just done it with a little gnashing
, not removing from disk.
Jeremy
-Original Message-
From: Themba Fletcher
Sent: Wednesday, December 21, 2011 4:40 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra
Well here's a fun thing that just happened:
tif@w...:~/Projects/ACSS/project
On Wed, 21 Dec 2011 16:52:54 -0500 Jeremy Cowgar wrote:
fossil rm should not remove a file it doesn't manage or has changes,
just like other SCM systems. In this case, the file in question has
changes, as it is brand new, the entire file has changed. Thus, if
you were to (in the future) do:
A -f option on rm and mv might do the trick. Default behavior doesn't
change. Add two characters to force the filesystem action.
On Wed, Dec 21, 2011 at 3:07 PM, Dmitry Chestnykh
dmi...@codingrobots.comwrote:
On Wed, 21 Dec 2011 16:52:54 -0500 Jeremy Cowgar wrote:
fossil rm should not remove
And talking about keeping cvs behavior: CVS delete command have a -f option to
delete the file from file system...
--
Martin
On 2011-12-21, at 19:10, Matt Welland estifo...@gmail.com wrote:
A -f option on rm and mv might do the trick. Default behavior doesn't
change. Add two characters to
55 matches
Mail list logo
