Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 the sync protocol would continue to be compatible, so Fossil 1.x can interact with Fossil 2.x projects. Only the operation of the various fossil commands would change, and only in ways that improve the interface, based on past experience. 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 rm removes the files from the disk (2) fossil mv renames the files on disk Two additional things I might like: (n+1) Allow more management of the repository through the web ui. For example, allow an administrator to delete, move, or rename files directly from the web ui. Or open or close a branch. Or merge two branches together. Or apply or remove a tag. ...etc... (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 want the vcs and the bug-tracking, but not the wiki or ui (though, in this scenario, tickets may need some way to be handled sans the web ui). By default, it would build everything like it does now, but a user could opt-out of certain elements. Note, this whole idea assumes that the different elements that make up fossil are not too tightly coupled ... but, if they _are_, we might wonder whether or not that is a good thing to begin with. -- Christopher Berardi http://www.natoufa.com/ May grace and peace by yours in abundance. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 want the vcs and the bug-tracking, but not the wiki or ui (though, in this scenario, tickets may need some way to be handled sans the web ui). By default, it would build everything like it does now, but a user could opt-out of certain elements. Note, this whole idea assumes that the different elements that make up fossil are not too tightly coupled ... but, if they _are_, we might wonder whether or not that is a good thing to begin with. Why is it important to you to have an executable that doesn't support the feature you don't use? Can't you simply not use the unwanted features even if they are included in the build? -- Christopher Berardi http://www.natoufa.com/ May grace and peace by yours in abundance. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 'core' vcs without the wiki, ui, or bug-tracking. Or, maybe I just want the vcs and the bug-tracking, but not the wiki or ui (though, in this scenario, tickets may need some way to be handled sans the web ui). By default, it would build everything like it does now, but a user could opt-out of certain elements. Note, this whole idea assumes that the different elements that make up fossil are not too tightly coupled ... but, if they _are_, we might wonder whether or not that is a good thing to begin with. Why is it important to you to have an executable that doesn't support the feature you don't use? Can't you simply not use the unwanted features even if they are included in the build? Besides if someone wanted a tool that did just one thing and did it well (ye old Unix principle), I can think of two use cases, embedded systems and sandboxed systems (though I can't think of a use case for the latter one). For example, I recently worked on a setup of distributed embedded systems that all shared a number of configuration files and some configuration files that had different settings and configurations. It would have been very handy to have fossil running keeping a versioned history of all the changes and each machine maintain a private branch for its specific configuration files. One of the key components of the setup was that everything could be replicated, and again fossil would aid in this. But, in an environment where I have to justify every kilobyte, being able to strip off what I don't need is invaluable. -- Christopher Berardi http://www.natoufa.com/ May grace and peace by yours in abundance. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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' vcs without the wiki, ui, or bug-tracking. Or, maybe I just want the vcs and the bug-tracking, but not the wiki or ui (though, in this scenario, tickets may need some way to be handled sans the web ui). By default, it would build everything like it does now, but a user could opt-out of certain elements. Note, this whole idea assumes that the different elements that make up fossil are not too tightly coupled ... but, if they _are_, we might wonder whether or not that is a good thing to begin with. Why is it important to you to have an executable that doesn't support the feature you don't use? Can't you simply not use the unwanted features even if they are included in the build? The if you don't use it costs nothing meme is wrong, and needs to die: http://blog.mired.org/2011/09/myth-of-costs-nothing.html That said, I don't think splitting up fossil's functionality is a good use of time - the default build is reasonably small and provides an excellent set of functionality. But if someone who feels otherwise provided a patch for it, I'd certainly be for accepting it, with the caveat that non-default builds aren't necessarily tested. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 shell's alias mechanism (I use zsh), but, as others replied, it's not convenient for non-Unix users and aliases are somehow part of today's modern DVCS-es. However, ability to select single branches for push/pull and rollback are standing much higher on my desired list for Fossil. Sincerely, Gour -- One who is not connected with the Supreme can have neither transcendental intelligence nor a steady mind, without which there is no possibility of peace. And how can there be any happiness without peace? http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 rm removes the files from the disk (2) fossil mv renames the files on disk (n+1) Ability to reference commit parents ala GIT: trunk^ is a main (non-merge) parent of the trunk; trunk^^ is parent-of-parent-of-trunk and so on. I am tired of cutting/pasting SHA1 hashes from web-gui to command-line and back. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 sometimes. Tomek On Wed, Feb 29, 2012 at 12:49 PM, Leo Razoumov slonik...@gmail.com wrote: 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 rm removes the files from the disk (2) fossil mv renames the files on disk (n+1) Ability to reference commit parents ala GIT: trunk^ is a main (non-merge) parent of the trunk; trunk^^ is parent-of-parent-of-trunk and so on. I am tired of cutting/pasting SHA1 hashes from web-gui to command-line and back. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 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. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 ci -n 1 -I 2
{
fossil:affb0019c9068467a6fe7cfbc76d0ca233721be3,
timestamp:1330545195,
command:timeline/ci,
procTimeMs:8,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
isLeaf:true,
user:stephan,
comment:fixed mis-matched ifdef for MSVC push/pop macros in cson
code.,
mtime:1330269600,
parentUuid:affb0019c9068467a6fe7cfbc76d0ca233721be3,
tags:[trunk]
}]
}
}
Note the parentUuid property.
:-?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 29, 2012 at 11:54 AM, Stephan Beal wrote:
On Wed, Feb 29, 2012 at 7:59 PM, Leo Razoumov slonik...@gmail.com
(mailto: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 ci -n 1 -I 2
{
fossil:affb0019c9068467a6fe7cfbc76d0ca233721be3,
timestamp:1330545195,
command:timeline/ci,
procTimeMs:8,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
isLeaf:true,
user:stephan,
comment:fixed mis-matched ifdef for MSVC push/pop macros in cson
code.,
mtime:1330269600,
parentUuid:affb0019c9068467a6fe7cfbc76d0ca233721be3,
tags:[trunk]
}]
}
}
Note the parentUuid property.
:-?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org)
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 worth while to change parentUuid to parents for the sake of consistency with the tags attribute? Absolutely. i'll try to get to that this weekend. i had never considered multiple parents (and i'm not sure _which_ parent is selected right now - the first, last, or unspecified!). Thanks, Brian! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 parent. I assume you model that. Actually... you've discovered a huge oversight. I think the only appropriate response is Oh snap. Would it be worth while to change parentUuid to parents for the sake of consistency with the tags attribute? Absolutely. i'll try to get to that this weekend. i had never considered multiple parents (and i'm not sure _which_ parent is selected right now - the first, last, or unspecified!). Thanks, Brian! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org) http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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,
uuid:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
...
parentUuid:affb0019c9068467a6fe7cfbc76d0ca233721be3,
parents:[affb0019c9068467a6fe7cfbc76d0ca233721be3],
tags:[trunk]
}]
}
}
With parentUuid now explicitly refering to the primary parent (i admit
that i have little idea what that really means). Incidentally, the
parents array puts the primary parent first, with the remaining elements
in unspecified order, so we could just as well drop parentUuid altogether.
:-?
Would it be worth while to change parentUuid to parents for the sake
of consistency with the tags attribute?
Absolutely. i'll try to get to that this weekend. i had never considered
multiple parents (and i'm not sure _which_ parent is selected right now -
the first, last, or unspecified!).
Thanks, Brian!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 parentUuid
b) defined the first element in the parents array to be the primary
parent.
stephan@tiny:~/cvs/fossil/fossil/src$ f json timeline ci -n 1 -I 2
{
fossil:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
timestamp:1330551627,
command:timeline/ci,
procTimeMs:16,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:0c9c99b83f936b44fd6c5d0ee5a308b48097e99f,
isLeaf:true,
user:stephan,
comment:/json/timeline/checkin: changed response payload to
include \parents\ array property with UUIDs of all parents, removing the
parentUuid property which just referenced the primary parent. The first
parent in the array is the primary parent. Thanks go to Brian Smith for
catching this oversight.,
mtime:1330551559,
parents:[ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d],
tags:[trunk]
}]
}
}
Documenting that change revealed a happy accident: parentUuid was (by
accident) not a documented property, so i'm not too likely to be breaking
someone's script code with this change.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 Smith br...@linuxfood.net
(mailto: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 parentUuid
b) defined the first element in the parents array to be the primary parent.
stephan@tiny:~/cvs/fossil/fossil/src$ f json timeline ci -n 1 -I 2
{
fossil:ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d,
timestamp:1330551627,
command:timeline/ci,
procTimeMs:16,
payload:{
limit:1,
timeline:[{
type:checkin,
uuid:0c9c99b83f936b44fd6c5d0ee5a308b48097e99f,
isLeaf:true,
user:stephan,
comment:/json/timeline/checkin: changed response payload to
include \parents\ array property with UUIDs of all parents, removing the
parentUuid property which just referenced the primary parent. The first
parent in the array is the primary parent. Thanks go to Brian Smith for
catching this oversight.,
mtime:1330551559,
parents:[ef561ed0a56a45a23ebf4f1cef6abbed8c98d38d],
tags:[trunk]
}]
}
}
Documenting that change revealed a happy accident: parentUuid was (by
accident) not a documented property, so i'm not too likely to be breaking
someone's script code with this change.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org (mailto:fossil-users@lists.fossil-scm.org)
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 will have a look in json API and I can write my own script to traverse the DAG, awesome! However, this basic functionality should had been in core fossil to begin with. I think the whole idea behind fossil design is to provide a single executable that does the job. I am afraid that if we start writing out-of-tree helper scripts sooner or later we will recreate GIT. BTW, can a commit have more than two parents? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
(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 request, though.
[1] http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg07419.html
Best regards,
Jacek
2012/2/28 Richard Hipp d...@sqlite.org:
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 --force|-f FILE1 FILE2 ...
where using '--force' option would make Fossil remove files fromn *both*
the project and the disk?
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 the sync protocol would continue to be compatible, so Fossil 1.x
can interact with Fossil 2.x projects. Only the operation of the various
fossil commands would change, and only in ways that improve the interface,
based on past experience.
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 rm removes the files from the disk
(2) fossil mv renames the files on disk
Sincerely,
Gour
--
The senses are so strong and impetuous, O Arjuna,
that they forcibly carry away the mind even of a man
of discrimination who is endeavoring to control them.
http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 --force|-f FILE1 FILE2 ... where using '--force' option would make Fossil remove files fromn *both* the project and the disk? 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 the sync protocol would continue to be compatible, so Fossil 1.x can interact with Fossil 2.x projects. Only the operation of the various fossil commands would change, and only in ways that improve the interface, based on past experience. 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 rm removes the files from the disk (2) fossil mv renames the files on disk Sincerely, Gour -- The senses are so strong and impetuous, O Arjuna, that they forcibly carry away the mind even of a man of discrimination who is endeavoring to control them. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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) fossil rm removes the files from the disk (2) fossil mv renames the files on disk Those are probably not interface changes, but here are few things I'd like to see in Fossil 2.0: a) Rollback for safe usage when one does not do auto-sync or when code is not pushed out into the wild universe. b) ability to push/pull single branches c) some aliasing mechanism so that user can create aliases for commands invoked with common options, e.g, ability to define cip = ci --private At the moment I cannot think about anything else which I'd like to see in Fossil to have all desired features presented in a superiorly simple package. ;) Stuff like incremental import/export might be handy for those having need to interoperate with other DVCS-es, but probably it's not so easy due to design decisions in Fossil. As far as I am concerned, I'm simply sold on Fossil's simplicity and will use it for our next open-source project and if 2.0 will solve some of the a) - c) items, it would be terrific!!! Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
(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 commit. People do not understand. Propose solutions RR 2012/2/28 Richard Hipp d...@sqlite.org: 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 --force|-f FILE1 FILE2 ... where using '--force' option would make Fossil remove files fromn *both* the project and the disk? 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 the sync protocol would continue to be compatible, so Fossil 1.x can interact with Fossil 2.x projects. Only the operation of the various fossil commands would change, and only in ways that improve the interface, based on past experience. 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 rm removes the files from the disk (2) fossil mv renames the files on disk Sincerely, Gour -- The senses are so strong and impetuous, O Arjuna, that they forcibly carry away the mind even of a man of discrimination who is endeavoring to control them. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 number of days) (6) Explain in more detail the clock problems with the commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) [1] http://fossil-scm.org/index.html/timeline?r=exp-search --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 nature, the ignorant fully engage themselves in material activities and become attached. But the wise should not unsettle them, although these duties are inferior due to the performers' lack of knowledge. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 a defined number of days) (6) Explain in more detail the clock problems with the commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) Anything starting with (3) is not about interface changes but rather these are feature requests. I have one feature request which does have something to do with interface: I'd like to see a set of sensible shortcuts to operate on tags for common cases, like make this commit start a branch named `mistake' (or a leaf of it) and then close this leaf immediately. Currently fossil has very low-level support for tags accessible from its command line which require deep level of knowledge about how tags are organized, what's the deal about symbolic vs raw tags, what are propagating tags etc--this is all plumbing commands (the term borrowed from Git lingo), and I, as a user, would like to have a set of higher-level commands to operate branches and leaves. Yes, I know about web interface (which is cool, no doubts) but I'm often using fossil while being logged over SSH where using `fossil server` is technically feasible but requires thinking about establishing SSH portforwarding up front which is inconvenient. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
(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 commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) (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 option to show hidden is selected. (useful to hide mistakes) RR 2012/2/28 Leo Razoumov slonik...@gmail.com: 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 number of days) (6) Explain in more detail the clock problems with the commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) [1] http://fossil-scm.org/index.html/timeline?r=exp-search --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
(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 commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) (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 option to show hidden is selected. (useful to hide mistakes) (10) Rebase - Different from git: Keep (and close) the original branch and apply all patches from the branch on top of a new base (maintaining commit messages). Name of the new branch could be same as old one. (11) Export/import of patches that supports file creation/movement/deletion, including binary files. May use a custom patch format. (12) Rollback / amendment to last commit(s) if not already pushed/pulled. (13) Web interface: Multiple sessions per user with option to logout from all sessions. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 update current (5) Unlimited undo (purgin old undos after a defined number of days) (6) Explain in more detail the clock problems with the commit. People do not understand. Propose solutions (7) push/pull individual branches (8) search through wiki pages, timeline, tickets (fossil-scm.org branch exp-search [1] can be a good start) (n+1) ability to scrub individual private branches. Right now fossil scrub --private nukes all private branches at once which IMHO is an overkill. I would like to be selective of what to remove and what remains. --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 option to show hidden is selected. (useful to hide mistakes) Is this really needed? After making a check-in a leaf in the mistake branch, close this leaf immediately; this way, the mistake branch at any point in time will contain only closed leaves and therefore it will be itself closed and not shown among the active branches. To me, the concept of hidden branches appears to be a misfeature. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 tip in that section has somehow alleviated the problem, but this inconvenient still remains there. For me, the all subsection of the files section should contain all the files of current and previous releases that we have not explicitly marked as of no interest anymore. One possible way of doing this would be to mark some branches as of no interest anymore for day to day work, except for archaeological purposes. RR 2012/2/28 Konstantin Khomoutov flatw...@users.sourceforge.net: 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 option to show hidden is selected. (useful to hide mistakes) Is this really needed? After making a check-in a leaf in the mistake branch, close this leaf immediately; this way, the mistake branch at any point in time will contain only closed leaves and therefore it will be itself closed and not shown among the active branches. To me, the concept of hidden branches appears to be a misfeature. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 you could place this in your .shrc file: alias cip='fossil ci --private' -- Christopher Berardi http://www.natoufa.com/ May grace and peace by yours in abundance. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 mechanism? For example, in a Bourne compatible shell you could place this in your .shrc file: alias cip='fossil ci --private' Not everyone uses Unix. Are there Windows shells supporting aliases, outside of 'mingw/bash' ? -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 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' Not everyone uses Unix. Are there Windows shells supporting aliases, outside of 'mingw/bash' ? Standard Windows Console has aliases. Type DOSKEY /? for documentation. The suggested alias would be defined by saying: DOSKEY cip=fossil ci --private $* Ideally you'd do this sort of thing in a batch file that you arrange to invoke when your command prompt launches. My project specific command-prompt shortcuts all at minimum specify a starting folder, and often use CMD /K C:\...\CUSTOMERSTART.BAT as the command line so that the specific batch file is run before CMD shows its first interactive prompt. That said, I can see utility for customizing aliases within fossil itself, so that CIP isn't now a general command but fossil cip does what the OP wanted. I'm not sure how generally useful this is given the strength of *nix and Windows aliases and shell scripts, however. Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 cip = ci --private 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' Not everyone uses Unix. Are there Windows shells supporting aliases, outside of 'mingw/bash' ? I think that Windows shortcut links (when they work) allow you to specify arguments to send. But, Windows isn't really command line friendly either way. -- Christopher Berardi http://www.natoufa.com/ May grace and peace by yours in abundance. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 remove files fromn *both* the project and the disk? Sincerely, Gour -- The senses are so strong and impetuous, O Arjuna, that they forcibly carry away the mind even of a man of discrimination who is endeavoring to control them. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 repository. Repository != file system to me. -1 settings option to ignore/include .dotfiles - supported in versionable settings --- this is already handled by the 'ignore-glob'. No need to have two settings that do the same thing. We can argue about whether or not the default setting for that should include */.* -1 status should also show files that might need to be added --- in my opinion you are asking the status of the repository. The repository reports changes / additions / deletions you've specified. Again, for me repository != filesystem. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 removing the file from the repository. The file - and it's entire history - is still there. You might be able to abuse shun to actually remove the file, but removing files from the repository is hard by design. What you're doing is causing future checkouts to the file system to not include a version of that file. You might argue that you're removing future versions from the repository, but future != now to me. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Behavior of rm, mv, and changes/extra
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 needs to adapt? I seem to be doing two steps for tasks that I preform dozens of times a day and that took one step in both git and hg. rm, mv: Managing files under source control in fossil is tedious, since I have to do every operation twice. One time for fossil and one time for the file system. Ex: $ fossil rm file1 DELETED file1 $ ls file1 $ rm file1 Is there a reason behind this design decision? I'm on the verge of creating my own wrapper script around fossil to get this done in one step. Especially at early stages of the project I perform these operations frequently. It just feels wrong to have to say the same thing (as I see it) twice. fossil changes; fossil extra; : These guys I just dont get. I had to write an alias in my bashrc just because it was getting really annoying. I use 'hg status' and 'git status' multiple times before I commit to get an instant look at what im doing: what file have I touched AND what new files have I created that I need to remember to add to source control. With fossil I have to execute two commands to get the same amount of information. If I do just fossil changes, I inevitably forget to 'fossil add' something. Again, this is especially relevant during the early stages of a project where things change much more dramatically (at least in my case.) To recap: Why not perform file system changes when fossil is instructed to delete or rename a file? Why not have a single command that gives you ALL differences between your working tree and the repository? Best, -Nick ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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. I wonder if an option isn’t in order maybe with a preference? Thus CVS guys can have it their way and normal 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 this design decision? Because that is the way CVS works. And Fossil was written to replace CVS as the CM system for SQLite. Oh, you mean a *good* reason for this behavior? Then the answer is no. I fear to change it now, though, since it might really mess up people who are used to the older style. I'm on the verge of creating my own wrapper script around fossil to get this done in one step. Especially at early stages of the project I perform these operations frequently. It just feels wrong to have to say the same thing (as I see it) twice. fossil changes; fossil extra; : These guys I just dont get. I had to write an alias in my bashrc just because it was getting really annoying. I use 'hg status' and 'git status' multiple times before I commit to get an instant look at what im doing: what file have I touched AND what new files have I created that I need to remember to add to source control. With fossil I have to execute two commands to get the same amount of information. If I do just fossil changes, I inevitably forget to 'fossil add' something. Again, this is especially relevant during the early stages of a project where things change much more dramatically (at least in my case.) To recap: Why not perform file system changes when fossil is instructed to delete or rename a file? Why not have a single command that gives you ALL differences between your working tree and the repository? Best, -Nick ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users wlEmoticon-openmouthedsmile[1].png___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 mv actually deleted and renamed files. On Wed, 21 Dec 2011 12:25:19 -0500 Richard Hipp wrote: I fear to change it now, though, since it might really mess up people who are used to the older style. I think this won't cause major problems, because the files are version controlled, after all. Or we can have a flag for destructive behavior for compatibility (but habits aside, it's better to have a flag for non-destructive behavior). -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 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 needs to adapt? I seem to be doing two steps for tasks that I preform dozens of times a day and that took one step in both git and hg. rm, mv: Managing files under source control in fossil is tedious, since I have to do every operation twice. One time for fossil and one time for the file system. Ex: $ fossil rm file1 DELETED file1 $ ls file1 $ rm file1 Is there a reason behind this design decision? Because that is the way CVS works. And Fossil was written to replace CVS as the CM system for SQLite. Oh, you mean a *good* reason for this behavior? Then the answer is no. I fear to change it now, though, since it might really mess up people who are used to the older style. Is this also why fossil (by default, anyways) ignores .dotfiles for example on fossil add? I've been using fossil daily for about six months, and it's my first experience with any kind of version control system. The above behavior, or more correctly the fact that I was not expecting it, caused me to get quite superstitious about parts of my deployment workflow when in fact the root cause was that I had not added the files to fossil that I thought I had. Clearly my fault for missing it in the fine manual, but you'll have that when you're learning a system :) So if there are any changes on the roadmap with respect to how fossil interacts with the filesystem I'd like to also advocate for changes to fossil add and fossil extra to stop ignoring dotfiles. Maybe with a default addition of .* to the ignore glob to maintain backwards compatibility? -- Themba Fletcher ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
+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 them when doing a rm? In any case, just print something like in the revert case: use fossil undo to get the file again RR 2011/12/21 Dmitry Chestnykh dmi...@codingrobots.com: If we're having a vote, +1. I'd like it if rm and mv actually deleted and renamed files. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 of the teeth. 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 to look after what I tell it to look after. My working directories usually contain a fair bit of transient junk that just does not need to be in the repository, but which I know I will need for a while. I can even see that I might want to keep a file no longer considered an official part of the project. In a way I blame git, encouraging people to do anything at all, then clean it up with a rebase (i.e. a lie) before letting it go to remote repositories. Another issue is that an SCM system is _not_ a backup tool, but many people seem to think that it is. And finally (for now :) ), dotfiles are special on *ix, so they should be treated specially. Eric P.S. Not picking on you, Dmitry, just using the first vote message to tack this onto. -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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. Why not? Do you have the truth about what a SCM must and must not do? One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. RR 2011/12/21 Eric e...@deptj.eu: 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 of the teeth. 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 to look after what I tell it to look after. My working directories usually contain a fair bit of transient junk that just does not need to be in the repository, but which I know I will need for a while. I can even see that I might want to keep a file no longer considered an official part of the project. In a way I blame git, encouraging people to do anything at all, then clean it up with a rebase (i.e. a lie) before letting it go to remote repositories. Another issue is that an SCM system is _not_ a backup tool, but many people seem to think that it is. And finally (for now :) ), dotfiles are special on *ix, so they should be treated specially. Eric P.S. Not picking on you, Dmitry, just using the first vote message to tack this onto. -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 gnashing of the teeth. If we're having a vote, +1. I'd like it if rm and mv actually deleted and renamed files. I think I favour it. But then we have to decide what to do, if the files had changes. fossil revert would not bring in the changes. And I don't think the 'remove' or 'rename' operations should change the undo buffer. Maybe the commands should require -f (force), if there are changes. Regards, Lluís. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 rm/delete's named changed if it's behavior isn't? forget, ignore or untrack are all more descriptive of what it actually does. Another issue is that an SCM system is _not_ a backup tool, but many people seem to think that it is. Why not? Do you have the truth about what a SCM must and must not do? One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. A backup tool stores files for later retrieval. If your SCM doesn't do that, it's not much of a SCM. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 to look after what I tell it to look after. 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. My working directories usually contain a fair bit of transient junk that just does not need to be in the repository, but which I know I will need for a while. I can even see that I might want to keep a file no longer considered an official part of the project. It won't do anything to your junk files -- fossil mv/rm deal with working tree files, which are registered with repository. But if you want to remove a file from the repository, but keep it in the working tree for a while, there could be an option for this. I think this scenario, though, is much less used compared to just wanting to remove files from the repository and the working copy. We should optimize for the common case. -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
So it goes beyond the strict definition of a SCM system, just like every other modern SCM system does. What's the problem (besides saving the user time which is money)? Jeremy -Original Message- From: Dmitry Chestnykh Sent: Wednesday, December 21, 2011 2:36 PM To: fossil-users@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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 backup tool, but many people seem to think that it is. Why not? Do you have the truth about what a SCM must and must not do? For my purposes, I do. One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. No it is not. Is you repository on the same disk as your working directory? And backup is for all your files, SCM is for important files that you need to keep the history of. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 from repository, but it does. Any chance of getting rm/delete's named changed if it's behavior isn't? forget, ignore or untrack are all more descriptive of what it actually does. Another issue is that an SCM system is _not_ a backup tool, but many people seem to think that it is. Why not? Do you have the truth about what a SCM must and must not do? One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. A backup tool stores files for later retrieval. If your SCM doesn't do that, it's not much of a SCM. Missing the point entirely. Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 is. Why not? Do you have the truth about what a SCM must and must not do? One of the nice things about a SCM system is that, in addition to more important features, it IS ALSO a backup tool. A backup tool stores files for later retrieval. If your SCM doesn't do that, it's not much of a SCM. Missing the point entirely. Yes, you did. In your other message, you said And backup is for all your files. That's true - you need to backup all your files. But files have different sources, uses and values, so may well be backed up with different strategies. Which may well call for different backup tools. Any tool that can store files for later retrieval could be part of such a system, and hence is a backup tool. On my desktop system, I use mirroring, snapshots, install media, the SCM, a LAN backup, a cloud server and fs duplicates as part of my backup strategy. I use Perforce to backup /etc and /usr/local/etc for a number of reasons. One is that I can put the server on a different system, so get non-local backups without further effort. Another is that it stores *everything* on the server, so there's no SCM cruft in /etc or /usr/local/etc, and I can recreate them *from scratch* with a simple p4 sync -f. Using a DSCM would be more complicated. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 of the teeth. If we're having a vote, +1. I'd like it if rm and mv actually deleted and renamed files. On Wed, 21 Dec 2011 12:25:19 -0500 Richard Hipp wrote: I fear to change it now, though, since it might really mess up people who are used to the older style. I think this won't cause major problems, because the files are version controlled, after all. Or we can have a flag for destructive behavior for compatibility (but habits aside, it's better to have a flag for non-destructive behavior). Well here's a fun thing that just happened: tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ site/common/classes/document_manager.php tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ | xargs fossil add ADDED site/common/classes/#document_manager.php# ADDED site/common/classes/document_manager.php So in the time it took me to type up-arrow | xargs fossil add my editor pulled an auto-save, and fossil added (2) files instead of one. Now I've got: 1. a file in my repo that I don't want 2. and it's not under version control, so I can't get it back if fossil deletes it It's a simple fossil rm away from being solved, but ... Assume a destructive fossil rm, and let's say the file is precious rather than just an autosave file. Lots of ways to get around the auto delete, but not necessarily obvious ones and someone, somewhere is going to learn how it works the first time by having fossil delete their file unexpectedly. Nope, I suddenly find myself a fan of the two step process as it stands. -- Themba Fletcher ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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: $ fossil rm #document_manager.php# File has changes, 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$ fossil extra | grep -v db/ site/common/classes/document_manager.php tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ | xargs fossil add ADDED site/common/classes/#document_manager.php# ADDED site/common/classes/document_manager.php So in the time it took me to type up-arrow | xargs fossil add my editor pulled an auto-save, and fossil added (2) files instead of one. Now I've got: 1. a file in my repo that I don't want 2. and it's not under version control, so I can't get it back if fossil deletes it It's a simple fossil rm away from being solved, but ... Assume a destructive fossil rm, and let's say the file is precious rather than just an autosave file. Lots of ways to get around the auto delete, but not necessarily obvious ones and someone, somewhere is going to learn how it works the first time by having fossil delete their file unexpectedly. Nope, I suddenly find myself a fan of the two step process as it stands. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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: $ fossil rm #document_manager.php# File has changes, not removing from disk. Exactly. Mercurial behavior is a bit different -- it doesn't remove it because the file has been marked for adding: ~ $ mkdir hg ~ $ cd hg ~/hg $ hg init ~/hg $ touch file.txt extra.txt ~/hg $ ls extra.txt file.txt ~/hg $ hg add file.txt extra.txt ~/hg $ hg rm extra.txt not removing extra.txt: file has been marked for add (use -f to force removal) -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 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: $ fossil rm #document_manager.php# File has changes, not removing from disk. Exactly. Mercurial behavior is a bit different -- it doesn't remove it because the file has been marked for adding: ~ $ mkdir hg ~ $ cd hg ~/hg $ hg init ~/hg $ touch file.txt extra.txt ~/hg $ ls extra.txt file.txt ~/hg $ hg add file.txt extra.txt ~/hg $ hg rm extra.txt not removing extra.txt: file has been marked for add (use -f to force removal) -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
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 force the filesystem action. On Wed, Dec 21, 2011 at 3:07 PM, Dmitry Chestnykh dmi...@codingrobots.com wrote: 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: $ fossil rm #document_manager.php# File has changes, not removing from disk. Exactly. Mercurial behavior is a bit different -- it doesn't remove it because the file has been marked for adding: ~ $ mkdir hg ~ $ cd hg ~/hg $ hg init ~/hg $ touch file.txt extra.txt ~/hg $ ls extra.txt file.txt ~/hg $ hg add file.txt extra.txt ~/hg $ hg rm extra.txt not removing extra.txt: file has been marked for add (use -f to force removal) -- Dmitry Chestnykh http://www.codingrobots.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
