Re: [fossil-users] cannot commit 'manifest file (1816) is malformed'
Hello Richard, I was going to write to you about reappearance of the 'malformed manifest' problem but found that you had checked in a fix to the previous bug fix. Now, I can confirm that the last fix [5f3a0681a0] works fine for me. Thank you, Jacek 2012/6/29 Richard Hipp d...@sqlite.org: On Fri, Jun 29, 2012 at 8:36 AM, Jacek Cała jacek.c...@gmail.com wrote: Thank you for the prompt action. Please keep me/the list informed about the patch. Please try the latest trunk version of Fossil. I believe it has fixed your issue and should be working for you now. Maybe it is also worth considering the case when a file has just been added to the repo (no commit) and then mv is issued from a MISSING to the ADDED file. I wrote about it a couple of days ago: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg08936.html Best regards, Jacek 2012/6/29 Richard Hipp d...@sqlite.org: On Fri, Jun 29, 2012 at 5:33 AM, Jacek Cała jacek.c...@gmail.com wrote: Hi, I've been doing some code maintenance (lots of deletes, renames, adds) and now cannot do commit. Every commit attempt causes: fossil.exe: manifest file (1816) is malformed. What does this mean? Is there any chance to fix the repo? My fossil version is 1.22. I have traced this problem to a bug in Fossil's manifest generator which causes rows of the manifest to be created out of order if you have done a fossil mv but then do a fossil commit FILENAME... where the renamed files are not being committed. Working on a fix now... Jacek ___ 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 -- 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
[fossil-users] Turning off change tracking for certain files
Hi All, I've got in my repo a small number of files that are changing but these changes are not meant to be send to the repo (are kind of user-specific). The files are needed in the repo but only in their initial or some specific version. Is there any way to turn off change tracking for some files? To be clearer, when doing 'fossil open myrepo' I'd like these files to appear in the filesystem but when doing 'fossil chan' I'd like them to not appear, maybe only when MISSING. I would expect this to work similar to 'fossil settings ignore-glob' w.r.t. 'fossil extra'. Cheers, Jacek ___ 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] Turning off change tracking for certain files
Hi! No, there us no such mechanism in fossil. I sometimes have similar problems with makefiles and config *files*, but i have never considered that to be an scm-level problem (maybe it is?). - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Jul 2, 2012 11:24 AM, Jacek Cała jacek.c...@gmail.com wrote: Hi All, I've got in my repo a small number of files that are changing but these changes are not meant to be send to the repo (are kind of user-specific). The files are needed in the repo but only in their initial or some specific version. Is there any way to turn off change tracking for some files? To be clearer, when doing 'fossil open myrepo' I'd like these files to appear in the filesystem but when doing 'fossil chan' I'd like them to not appear, maybe only when MISSING. I would expect this to work similar to 'fossil settings ignore-glob' w.r.t. 'fossil extra'. Cheers, Jacek ___ 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] Turning off change tracking for certain files
Hi Stephan, I think it is an scm-level problem, at least for me ;-) The thing is that either I'll commit these file every time they change (which makes a bit of mess in the repo) or I need to do a selective commit which omits these files (which after a tens of commits become a bit annoying). Cheers, Jacek 2012/7/2 Stephan Beal sgb...@googlemail.com: Hi! No, there us no such mechanism in fossil. I sometimes have similar problems with makefiles and config files, but i have never considered that to be an scm-level problem (maybe it is?). - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Jul 2, 2012 11:24 AM, Jacek Cała jacek.c...@gmail.com wrote: Hi All, I've got in my repo a small number of files that are changing but these changes are not meant to be send to the repo (are kind of user-specific). The files are needed in the repo but only in their initial or some specific version. Is there any way to turn off change tracking for some files? To be clearer, when doing 'fossil open myrepo' I'd like these files to appear in the filesystem but when doing 'fossil chan' I'd like them to not appear, maybe only when MISSING. I would expect this to work similar to 'fossil settings ignore-glob' w.r.t. 'fossil extra'. Cheers, Jacek ___ 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
Re: [fossil-users] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 1:19 PM, Jacek Cała jacek.c...@gmail.com wrote: The thing is that either I'll commit these file every time they change (which makes a bit of mess in the repo) or I need to do a selective commit which omits these files (which after a tens of commits become a bit annoying). Coincidentally, i had just the same problem all last weekend, where i didn't want to commit my makefile changes to the main repo (owned by someone else). Before every commit i had to remove my Makefile symlink and revert the old copy to ensure that i didn't hose the original, and afterwards had to delete the in-tree copy and symlink it over to my makefile. Annoying, yes, and i eventually worked around it by restructuring the build to allow for a developer-local makefile to set up the local build configuration before including the master makefile. So the problem is there, yes, but i don't see how an SCM can help with that particular case. It sees the original versions and considers any file with a name it knows about to be under SCM control. i think that's a fair assumption (and there's not an SCM out there which does not do this). i'm not personally convinced that an ignore list would completely solve the problem (i think that just might lead to more confusion (i changed the file, why isn't it showing as changed?) and corresponding bug reports). But it might be a solution or part of a solution. Can you elaborate on how you imagine such a feature behaving? -- - 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal sgb...@googlemail.com wrote: i'm not personally convinced that an ignore list would completely solve the problem (i think that just might lead to more confusion (i changed the file, why isn't it showing as changed?) and corresponding bug reports). But it might be a solution or part of a solution. Can you elaborate on how you imagine such a feature behaving? Maybe we could have a local list, similar to ignore-glob, like: fossil forget-local ...list...of...files... fossil remember-local ...list...of...files... (undoes the forget) Forgotten files would be excluded from commits unless they are explicitly named on the command-line (as opposed to being in a directory which was passed on the comment line). Fossil status should probably show them as changed, in any case. But what happens if the remote is updated? Do those files participate in merging (i suspect they should)? Are there other corner cases here? -- - 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal sgb...@googlemail.comwrote: i'm not personally convinced that an ignore list would completely solve the problem (i think that just might lead to more confusion (i changed the file, why isn't it showing as changed?) and corresponding bug reports). But it might be a solution or part of a solution. Can you elaborate on how you imagine such a feature behaving? Maybe we could have a local list, similar to ignore-glob, like: fossil forget-local ...list...of...files... fossil remember-local ...list...of...files... (undoes the forget) Forgotten files would be excluded from commits unless they are explicitly named on the command-line (as opposed to being in a directory which was passed on the comment line). Fossil status should probably show them as changed, in any case. But what happens if the remote is updated? Do those files participate in merging (i suspect they should)? Are there other corner cases here? I am willing to *consider* some option that says do not commit these files, even if they change, unless that are specifically named on the command-line. I think this would be easy to implement by messing with the is_selected()/if_selected() function http://www.fossil-scm.org/fossil/artifact/9b15f53f6?ln=1366-1385. So, to use Stephan's example, if you marked Makefile as no-autocommit, and there were changes to both Makefile and to file1.txt, fossil commit would only check-in the changes on file1.txt. But fossil commit Makefile *.txt would check-in changes to both file. Probably there should be another command-line option such as fossil commit --all that also picks up Makefile. The changes command should show the changes to Makefile, but indicate that they are not checked in by default. The check-in comment prompt string should indicate clearly that Makefile is omitted from the check-in because of the setting and it was not specified on the command-line. I don't think any changes are needed to update or merge or stash. fossil revert is an interesting case - does it revert Makefile to the default, or doesn't it? Maybe fossil revert Makefile or fossil revert --all is required? Correction: I think fossil changes should only show Makefile if you give it an option like --all. Otherwise, fossil all changes (whose purpose it to show check-outs with any changes that you have forgotten to check-in) would give false hits for repos with only Makefile-like changes. -- - 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 -- 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] Turning off change tracking for certain files
This is exactly how I would expect it to work. And I like the '--all' option, too. The only thing is if anything better than a list like 'ignore-glob' can be proposed. In my case it's just a few files, so such a list would be enough. However, I can imagine that someone has a large repo and needs to set no-autocommit to more than 10 files. Then maintaining an 'ignore-glob'-like list may become a pain. Cheers, Jacek 2012/7/2 Richard Hipp d...@sqlite.org: I am willing to *consider* some option that says do not commit these files, even if they change, unless that are specifically named on the command-line. I think this would be easy to implement by messing with the is_selected()/if_selected() function. So, to use Stephan's example, if you marked Makefile as no-autocommit, and there were changes to both Makefile and to file1.txt, fossil commit would only check-in the changes on file1.txt. But fossil commit Makefile *.txt would check-in changes to both file. Probably there should be another command-line option such as fossil commit --all that also picks up Makefile. The changes command should show the changes to Makefile, but indicate that they are not checked in by default. The check-in comment prompt string should indicate clearly that Makefile is omitted from the check-in because of the setting and it was not specified on the command-line. I don't think any changes are needed to update or merge or stash. fossil revert is an interesting case - does it revert Makefile to the default, or doesn't it? Maybe fossil revert Makefile or fossil revert --all is required? Correction: I think fossil changes should only show Makefile if you give it an option like --all. Otherwise, fossil all changes (whose purpose it to show check-outs with any changes that you have forgotten to check-in) would give false hits for repos with only Makefile-like changes. -- - 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 -- 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała jacek.c...@gmail.com wrote: would be enough. However, I can imagine that someone has a large repo and needs to set no-autocommit to more than 10 files. Then maintaining an 'ignore-glob'-like list may become a pain. fossil/sqlite has routines for globbing, so it wouldn't be too painful to do things like: fossil remember-local 'foo.*' (quoting the wildcard so that sqlite gets it instead of having the shell expand it) -- - 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] Turning off change tracking for certain files
2012/7/2 Stephan Beal sgb...@googlemail.com: On Mon, Jul 2, 2012 at 2:49 PM, Jacek Cała jacek.c...@gmail.com wrote: would be enough. However, I can imagine that someone has a large repo and needs to set no-autocommit to more than 10 files. Then maintaining an 'ignore-glob'-like list may become a pain. fossil/sqlite has routines for globbing, so it wouldn't be too painful to do things like: fossil remember-local 'foo.*' Fine for me! Jacek ___ 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] Turning off change tracking for certain files
One more thought. Perhaps, there's no need for a separate ignore list but just a bit different semantics of the existing 'ignore-glob'. Couldn't it just be that when a file (a set of files '*.whatever') is in the ignore-glob it behaves exactly like Richard suggested. From a user perspective that would be simpler -- just one list which means ignore yet not prevent from being added. Cheers, Jacek 2012/7/2 Richard Hipp d...@sqlite.org: On Mon, Jul 2, 2012 at 7:56 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 2, 2012 at 1:44 PM, Stephan Beal sgb...@googlemail.com wrote: i'm not personally convinced that an ignore list would completely solve the problem (i think that just might lead to more confusion (i changed the file, why isn't it showing as changed?) and corresponding bug reports). But it might be a solution or part of a solution. Can you elaborate on how you imagine such a feature behaving? Maybe we could have a local list, similar to ignore-glob, like: fossil forget-local ...list...of...files... fossil remember-local ...list...of...files... (undoes the forget) Forgotten files would be excluded from commits unless they are explicitly named on the command-line (as opposed to being in a directory which was passed on the comment line). Fossil status should probably show them as changed, in any case. But what happens if the remote is updated? Do those files participate in merging (i suspect they should)? Are there other corner cases here? I am willing to *consider* some option that says do not commit these files, even if they change, unless that are specifically named on the command-line. I think this would be easy to implement by messing with the is_selected()/if_selected() function. So, to use Stephan's example, if you marked Makefile as no-autocommit, and there were changes to both Makefile and to file1.txt, fossil commit would only check-in the changes on file1.txt. But fossil commit Makefile *.txt would check-in changes to both file. Probably there should be another command-line option such as fossil commit --all that also picks up Makefile. The changes command should show the changes to Makefile, but indicate that they are not checked in by default. The check-in comment prompt string should indicate clearly that Makefile is omitted from the check-in because of the setting and it was not specified on the command-line. I don't think any changes are needed to update or merge or stash. fossil revert is an interesting case - does it revert Makefile to the default, or doesn't it? Maybe fossil revert Makefile or fossil revert --all is required? Correction: I think fossil changes should only show Makefile if you give it an option like --all. Otherwise, fossil all changes (whose purpose it to show check-outs with any changes that you have forgotten to check-in) would give false hits for repos with only Makefile-like changes. -- - 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 -- 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała jacek.c...@gmail.com wrote: One more thought. Perhaps, there's no need for a separate ignore list but just a bit different semantics of the existing 'ignore-glob'. In my experience, changing/extending semantics means lots of new room for special cases and backwards compatibility problems. :/. Couldn't it just be that when a file (a set of files '*.whatever') is in the ignore-glob it behaves exactly like Richard suggested. From a user perspective that would be simpler -- just one list which means ignore yet not prevent from being added. How could the ignore code differentiate between truly ignored files and those which are partially ignored? -- - 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] Turning off change tracking for certain files
2012/7/2 Stephan Beal sgb...@googlemail.com: On Mon, Jul 2, 2012 at 3:04 PM, Jacek Cała jacek.c...@gmail.com wrote: Couldn't it just be that when a file (a set of files '*.whatever') is in the ignore-glob it behaves exactly like Richard suggested. From a user perspective that would be simpler -- just one list which means ignore yet not prevent from being added. How could the ignore code differentiate between truly ignored files and those which are partially ignored? Is there any difference except from being in the repo. I'd say, truly ignored files are not in the repo at all, while partially ignored happen to be although the scm just ignores their local counterparts. Am I missing something? Jacek ___ 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 5:24 AM, Jacek Cała jacek.c...@gmail.com wrote: Hi All, I've got in my repo a small number of files that are changing but these changes are not meant to be send to the repo (are kind of user-specific). The files are needed in the repo but only in their initial or some specific version. Is there any way to turn off change tracking for some files? To be clearer, when doing 'fossil open myrepo' I'd like these files to appear in the filesystem but when doing 'fossil chan' I'd like them to not appear, maybe only when MISSING. I would expect this to work similar to 'fossil settings ignore-glob' w.r.t. 'fossil extra'. This would be very useful for those IDE that modify a timestamp string in the project file every time the project is open even without any modifications.. Martin G. ___ 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała jacek.c...@gmail.com wrote: Is there any difference except from being in the repo. I'd say, truly ignored files are not in the repo at all, while partially ignored happen to be although the scm just ignores their local counterparts. Am I missing something? That's my point: fossil has to completely ignore one set and only deal with the other set in certain cases. In order to that, it has to be able to differentiate between the two sets of files. It can't do that if they're all in the ignore-glob (which has very specific semantics which users rely upon). In any case, Richard indicated that it shouldn't be too hard to implement using existing functionality. i can't personally commit to implementing it in the near future, but it's something i'd like to see at least experimentally implemented. In hindsight, i can't believe this feature suggestion has never come up before :/. -- - 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] Turning off change tracking for certain files
If it happens I have some spare time, I'll look on the
{is/if}_selected and will report on any progress.
Cheers,
Jacek
2012/7/2 Stephan Beal sgb...@googlemail.com:
On Mon, Jul 2, 2012 at 3:09 PM, Jacek Cała jacek.c...@gmail.com wrote:
Is there any difference except from being in the repo. I'd say,
truly ignored files are not in the repo at all, while partially
ignored happen to be although the scm just ignores their local
counterparts. Am I missing something?
That's my point: fossil has to completely ignore one set and only deal with
the other set in certain cases. In order to that, it has to be able to
differentiate between the two sets of files. It can't do that if they're all
in the ignore-glob (which has very specific semantics which users rely
upon).
In any case, Richard indicated that it shouldn't be too hard to implement
using existing functionality. i can't personally commit to implementing it
in the near future, but it's something i'd like to see at least
experimentally implemented. In hindsight, i can't believe this feature
suggestion has never come up before :/.
--
- 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
Re: [fossil-users] Turning off change tracking for certain files
On Mon, 2 Jul 2012 08:08:18 -0400 Richard Hipp d...@sqlite.org wrote: I am willing to *consider* some option that says do not commit these files, even if they change, unless that are specifically named on the command-line. I think this would be easy to implement by messing with the is_selected()/if_selected() function http://www.fossil-scm.org/fossil/artifact/9b15f53f6?ln=1366-1385. My issue with this solution is that this doesn't really solve the problem as I've encountered it. That is, a config file that needs local changes to run/build, but with a base version in the repo that needs evolves along with the project. My solution has been to push things out to the build system. What gets stored in the repo is config.template. In this, the values for everything document what they are used for. The end user (or a command run by them, depending) creates config from that, filling in the values as appropriate. The build (or launch, depending) system breaks if the local version doesn't exist, and issues a warning if the template is newer than the local copy (when it gets updated). A SCM system could do that, with a private branch of the config file for everyone who is building (running) the project, but that seems like overkill. 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] Turning off change tracking for certain files
On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer m...@mired.org wrote: My solution has been to push things out to the build system. What gets stored in the repo is config.template. In this, the values for Another option might, depending on the system, be to include a local config file/make file/whatever. e.g. in Make it might look like: -include Makefile.$(USER) the - before include means don't fail if the file does not exist, and most devs have the same $(USER) on their dev machine(s). (And if they don't, a symlink can work as a crutch to link multiple names to one makefile.) For small teams, Makefile.$(USER) might even be checked in. The Ant build system allows one to include custom property files, so you could add local.config to your imports and you're all set. Developers which don't need it simply need to create a 0-byte copy locally. -- - 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] Turning off change tracking for certain files
Just a general comment on this proposal To reiterate the solution provided by Mike, I think this problem can be easily solved by user methodology with no changes to fossil. If you have generated or user edited files create and check in templates. Add the appropriate targets to your make file to copy (and possibly modify) the template to the needed file if it does not exist. These special case files are going to be one more thing a new user has to learn and deal with and the ROI is very low. It will be hard to see the different status between a normally controlled file and the special file. An alternative would be to consider the git model where you have to mark files for commit. It is a general solution that does address this need. On Mon, Jul 2, 2012 at 6:55 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 2, 2012 at 3:52 PM, Mike Meyer m...@mired.org wrote: My solution has been to push things out to the build system. What gets stored in the repo is config.template. In this, the values for Another option might, depending on the system, be to include a local config file/make file/whatever. e.g. in Make it might look like: -include Makefile.$(USER) the - before include means don't fail if the file does not exist, and most devs have the same $(USER) on their dev machine(s). (And if they don't, a symlink can work as a crutch to link multiple names to one makefile.) For small teams, Makefile.$(USER) might even be checked in. The Ant build system allows one to include custom property files, so you could add local.config to your imports and you're all set. Developers which don't need it simply need to create a 0-byte copy locally. -- - 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
[fossil-users] build fossil with ssl support on debian and ubuntu
Dear all, Since the precompiled fossil comes without ssl support, I would like to compile fossil myself, for Debian and Ubuntu. Unfortunately, I am not sure how to do so: both $ ./configure --with-openssl=auto and $ ./configure --with-openssl=/usr/bin/ yield Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options I should add that openssl is installed: $ which openssl /usr/bin/openssl Could anybody tell me how to compile fossil with openssl on Debian/Ubuntu, please? Thanks a lot. Best, Benedikt ___ 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] build fossil with ssl support on debian and ubuntu
I think you need: apt-cache search openssl dev Then install the dev package it lists. Sorry for the brevity - on a tablet. On Jul 2, 2012 11:21 PM, ahrens benedikt.ahr...@gmx.net wrote: Dear all, Since the precompiled fossil comes without ssl support, I would like to compile fossil myself, for Debian and Ubuntu. Unfortunately, I am not sure how to do so: both $ ./configure --with-openssl=auto and $ ./configure --with-openssl=/usr/bin/ yield Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support Try: 'configure --help' for options I should add that openssl is installed: $ which openssl /usr/bin/openssl Could anybody tell me how to compile fossil with openssl on Debian/Ubuntu, please? Thanks a lot. Best, Benedikt ___ 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] build fossil with ssl support on debian and ubuntu
On Mon, 02 Jul 2012 23:21:39 +0200 ahrens benedikt.ahr...@gmx.net wrote: I should add that openssl is installed: $ which openssl /usr/bin/openssl That's the binary, not the bits you need to compile code that uses it. Just one of the many reasons I develop on FreeBSD: they don't do that. If you had openssl installed, you'd have the bits you needed. Could anybody tell me how to compile fossil with openssl on Debian/Ubuntu, please? I recommend aptitude for this: sudo install build-dep fossil Which will install all the build dependencies used by the fossil binary you installed. That way, you'll get any that are missing besides openssl. Of course, if it's not in your repository, or they built it without openssl, you'll be out of luck. 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] build fossil with ssl support on debian and ubuntu
Error: OpenSSL not found. Consider --with-openssl=none to disable HTTPS support On Debian, install libssl-dev. Also if you're on amd64, I recommend building a shared version, I can't remember the details, only that I had great trouble building a static binary and gave up. Thanks, Kev ___ 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] Stupid newbie question: attempt to write a readonly database
Thanks heaps. That was a pretty stupid mistake. Just for the next person with the same problem, my Fossil directory and cgi-bin directory were both owned by root for some reason. To fix this I ran $ sudo chown -R USERNAME:GROUP cgi-bin/ $ sudo chown -R USERNAME:GROUP Fossil/ with USERNAME and GROUP, obviously being replaced with my username and group. Thanks again. On 1 July 2012 20:28, Lluís Batlle i Rossell vi...@viric.name wrote: On Sun, Jul 01, 2012 at 12:16:55PM +0200, Stephan Beal wrote: On Sun, Jul 1, 2012 at 12:16 PM, Stephan Beal sgb...@googlemail.com wrote: On Sun, Jul 1, 2012 at 11:47 AM, Robin Shannon r...@robinshannon.netwrote: SQLITE_CANTOPEN: cannot open file at line 27473 of [2677848087] The directory containing the db also has to be writable by the CGI process. PS: that's necessary for the db journaling files. Notice that the user running the cgi may not be the user owning the db file and folder. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- http://robinshannon.net ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
