[fossil-users] ls_cmd patch for consistency
'fossil status' and 'fossil changes' report missing files as MISSING,
while 'fossil ls -v' incorrectly calls them ADDED.
The following patch rearranges the order of file status checks in
ls_cmd() to make it behave like status_report()
Index: checkin.c
==
--- checkin.c
+++ checkin.c
@@ -349,20 +349,20 @@
int chnged = db_column_int(q,3);
int renamed = db_column_int(q,4);
char *zFullName = mprintf(%s%s, g.zLocalRoot, zPathname);
const char *type = ;
if( verboseFlag ){
- if( isNew ){
-type = ADDED ;
- }else if( isDeleted ){
+ if( isDeleted ){
type = DELETED;
}else if( !file_wd_isfile_or_link(zFullName) ){
if( file_access(zFullName, F_OK)==0 ){
type = NOT_A_FILE ;
}else{
type = MISSING;
}
+ }else if( isNew ){
+type = ADDED ;
}else if( chnged ){
if( chnged==2 ){
type = UPDATED_BY_MERGE ;
}else if( chnged==3 ){
type = ADDED_BY_MERGE ;
A month ago I managed to post a ticket about that subject:
https://www.fossil-scm.org/fossil/tktview?name=92fedcbc7d
Since then I learned that tickets are seldom reviewed...
Q: Is that the reason why there is no more new ticket for anonymous users?
-Tontyna
___
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] Timeline pointers patch
On 3/6/15, Richard Hipp d...@sqlite.org wrote: On 3/6/15, Chad Clabaugh chadclaba...@gmail.com wrote: I would like to offer the attached patch to timeline.c that smooths the timeline arrows while also halving the number of elements required to create them. I tried this (using Firefox Nightly) but it doesn't look right. Legacy: http://www.fossil-scm.org/tmp/ss-legacy.gif New: http://www.fossil-scm.org/tmp/ss-legacy.gif Correct link to new: http://www.fossil-scm.org/tmp/ss-new.gif As you can see, the new code is asymmetric and the arrow tips do not reach the bottom of the boxes. -- D. Richard Hipp d...@sqlite.org -- 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] Timeline pointers patch
On 3/6/15, Chad Clabaugh chadclaba...@gmail.com wrote: I would like to offer the attached patch to timeline.c that smooths the timeline arrows while also halving the number of elements required to create them. I tried this (using Firefox Nightly) but it doesn't look right. Legacy: http://www.fossil-scm.org/tmp/ss-legacy.gif New: http://www.fossil-scm.org/tmp/ss-legacy.gif As you can see, the new code is asymmetric and the arrow tips do not reach the bottom of the boxes. -- 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] Extending fossil ls
Hello, Attached is a bundle with a proposal how to extend fossil ls with -r and -R flags, to be able to list contents of any revision. The flags work like in fossil cat. This gives the command line access to information similar to certain web pages e.g. fileage?name=rev, tree?ci=rev and dir?ci=rev. The first commit in the bundle has a more verbose output, but I then opted for a smaller version. /Peter ls.bundle Description: Binary data ___ 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] Justification for two-step mv and rm
On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna tont...@ultrareal.de wrote: I'm in the 1%, too. Perhaps that's because of my OS being Windows and me being a Fossil newbie. Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. personally, I would _not_ like to see a mandatory `--forcefilesystem' option in order to get the usually desired behaviour. otherwise, see the previous mail by jan nijtmans which proposes a very sensible solution in my view: create a new alias `forget' for the current `rm' (which then should become the sole command performing that sort of operation (removing file from `fossil' tracking w/o touching file system) in due time -- thr sooner the better ...) and start to use the already existing `rename' instead of `mv'. this would ease the way of making rm/mv act like they really should (in the view of most people I really would say -- and that's an important criterion w.r.t. what a good default behavior should be) namely like what is happening in `hg' (I agree with warren young that the `hg' people seemingly have thought long enough about this and found a good solution and implemented enough options to cover all relevant use cases). another point which has already been made in this thread, but might be emphasized: of course `mv' and `rm' already touch the file system quite regularly namely on the other end: someone updating from your repository (or your remote repo to which you (auto)sync)) after you performed `mv' or `rm' will of course modify his checkout (as indeed, it should). it makes (usually, but not always I admit) no sense that locally one has to go again and again through the routine of mirroring each and every `fossil rm' and `fossil mv' by a corresponding file system action. I understand that some people _want_ this but there needs would be satisfied if that is achieved by `rename/forget' in the future. -Tontyna BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. Am 04.03.2015 um 18:24 schrieb paul: On 03/03/15 22:27, j. van den hoff wrote: . so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. If fossil mv also moves files on a filesystem, I'd be happy with that, so long as I can still use a file browser as I'm doing now. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] Justification for two-step mv and rm
Am 06.03.2015 um 15:46 schrieb j. van den hoff: On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna tont...@ultrareal.de wrote: I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. personally, I would _not_ like to see a mandatory `--forcefilesystem' option in order to get the usually desired behaviour. I totally agree, the --forcefilesystem was just a reminisence to the '-f' option proposed in previous mails. Too many options for any command are puzzling, always have to lookup what the command does depending on the applied flags. otherwise, see the previous mail by jan nijtmans which proposes a very sensible solution in my view: create a new alias `forget' for the current `rm' (which then should become the sole command performing that sort of operation (removing file from `fossil' tracking w/o touching file system) in due time -- thr sooner the better ...) and start to use the already existing `rename' instead of `mv'. this would ease the way of making rm/mv act like they really should (in the view of most people I really would say -- and that's an important criterion w.r.t. what a good default behavior should be) namely like what is happening in `hg' (I agree with warren young that the `hg' people seemingly have thought long enough about this and found a good solution and implemented enough options to cover all relevant use cases). On Windows neither `mv` nor `rm` does suggest anything to me other than what `fossil help` tells; but since the majority here associates touch the file system with those words it seems to be a good idea to let the commands exactly do that. I don't mind how the commands are named as long as they exist. Much cleaner to have different commands for different tasks. Even better when the command is self-explanatory. another point which has already been made in this thread, but might be emphasized: of course `mv' and `rm' already touch the file system quite regularly namely on the other end: someone updating from your repository (or your remote repo to which you (auto)sync)) after you performed `mv' or `rm' will of course modify his checkout (as indeed, it should). it makes (usually, but not always I admit) no sense that locally one has to go again and again through the routine of mirroring each and every `fossil rm' and `fossil mv' by a corresponding file system action. I understand that some people _want_ this but there needs would be satisfied if that is achieved by `rename/forget' in the future. Good to mention that point -- almost forgot that one of the reasons to introduce a CVS instad of only syncing directories is the question of how to get rid of unused garbage (there is always at least one developer creating 'old/', '.keep' an the likes an never deleting anything just in case) ___ 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] Justification for two-step mv and rm
I'm in the 1%, too. Perhaps that's because of my OS being Windows and me being a Fossil newbie. Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. -Tontyna BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. Am 04.03.2015 um 18:24 schrieb paul: On 03/03/15 22:27, j. van den hoff wrote: . so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. If fossil mv also moves files on a filesystem, I'd be happy with that, so long as I can still use a file browser as I'm doing now. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ 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] Justification for two-step mv and rm
2015-03-06 1:32 GMT+01:00 jungle Boogie jungleboog...@gmail.com: On 5 March 2015 at 12:49, Roy Marples r...@marples.name wrote: Add flag -f to mv and rm to do this? Allows the desired feature and is sort of similar to CVS fossil mv -f file1 file2 fossil rm -f file1 file2 Yes, this seems simple and easy enough to type. There may be some objections as it may be be full featured, though. The biggest problem with fossil rm and fossil mv is that it suggests to remove/move a file on the file system, but it doesn't. In stead it makes fossil forget/rename the file in the repository. fossil rename already exists as alias to fossil mv, so I suggest to add fossil forget as alias to fossil rm. Then later the behavior of fossil rm/mv can be modified, while forget/rename will continue to behave as rm/mv do now. Any objections against adding fossil forget as alias to fossil rm If not, I'll be glad to add it, awaiting further discussion. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Timeline pointers patch
I would like to offer the attached patch to timeline.c that smooths the timeline arrows while also halving the number of elements required to create them. For current trunk [ad6e4004] https://www.fossil-scm.org/index.html/info/ad6e4004592807fb smoothTimelineArrows.patch Description: Binary data ___ 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] Timeline pointers patch
Certainly. I went with fossil diff. On Fri, Mar 6, 2015 at 10:53 AM, Richard Hipp d...@sqlite.org wrote: On 3/6/15, Chad Clabaugh chadclaba...@gmail.com wrote: I would like to offer the attached patch to timeline.c that smooths the timeline arrows while also halving the number of elements required to create them. For current trunk [ad6e4004] https://www.fossil-scm.org/index.html/info/ad6e4004592807fb I'm stressed over an unrelated issue (https://www.sqlite.org/src/info/05f43be8fdda9fbd) right now. So you could help me out by sending the patch as either (1) fossil diff or (2) fossil diff --tk and then use the SaveAs button to generate a Tcl script that shows the side-by-side diff or (3) check in your change to a branch on your local copy of the repo and then run fossil bundle ... to create a bundle for your patch and send me the bundle. The raw diff style patch is difficult to read, and I need to be expending my energies on the bug above right now, rather than trying to decode it. Thanks. -- 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 smoothTimelineArrows.patch Description: Binary data ___ 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] Justification for two-step mv and rm
On 06/03/15 15:10, Jan Nijtmans wrote: [---] fossil rename already exists as alias to fossil mv, so I suggest to add fossil forget as alias to fossil rm. Then later the behavior of fossil rm/mv can be modified, while forget/rename will continue to behave as rm/mv do now. Any objections against adding fossil forget as alias to fossil rm If not, I'll be glad to add it, awaiting further discussion. No objection. I'm even going to go so far as to say I'll be cheering you on. /Jan ___ 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] Justification for two-step mv and rm
On Fri, Mar 6, 2015 at 9:11 AM, Tontyna tont...@ultrareal.de wrote: Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. I am curious which IDE you and your team are using. Also, why you chose to write a stand-alone GUI application for Fossil rather than configure your IDE to interact with Fossil. Curiously, I've found that the open source IDEs I've tried actually make it harder to integrate new VCSs. Up until recently, my team and I used the SlickEdit IDE. It has very easy to configure support for any command line VCS. (Sadly, when the company decided to not renew the support contract, a manager in IT decided that meant we no longer had a license to use it - despite the fact that the license itself stated it is a perpetual license for the specified version.) ___ 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] Justification for two-step mv and rm
Am 06.03.2015 um 18:45 schrieb Ron W: On Fri, Mar 6, 2015 at 9:11 AM, Tontyna tont...@ultrareal.de mailto:tont...@ultrareal.de wrote: Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. I am curious which IDE you and your team are using. Also, why you chose to write a stand-alone GUI application for Fossil rather than configure your IDE to interact with Fossil. It's mainly Embarcadero Delphi and of course it's possible to write widgets or post-build-scripts to do basic stuff and for shure I'll do that. Root cause for the GUI is: To incline my boss towards Fossil we need something he will integrate without grumbling into his personal workflow. Some other reasons are - explore Fossil in a comfortable way - our products contain many files the IDE has no clue of - psycho-wise it serves the feeling of being in charge ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
