Re: [fossil-users] How do I rebuild my fossil repo?
With help of some scripting and SQL, you can find all UUIDs for files that you want to remove and shun them. after that when you rebuild, your repo file will be shrunk. It is a bit effort though. - Original Message - From: Stephan Beal Sent: 07/05/12 09:15 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How do I rebuild my fossil repo? Nothing can be removed from fossil. Ever. There is no way to shrink a repo, only to re-create it with the desired files. On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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] Support for Zscaler proxy...
Update: fossil does work through the proxy. Problem seems to be with the proxy, it gives 'bad request' error when user@ is added to URL in POST method. I'll work with IT folks for fixing it. - Original Message - From: altufa...@mail.com Sent: 05/15/12 03:57 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Support for Zscaler proxy... It seems fossil sends POST method to proxy server (I tried fossil pull ...). I tested git through proxy (socat - proxy:wwwproxy:$1:$2,proxyport=80) and it works, using CONNECT method. I'll look at ssl code to see if non-ssl can also use CONNECT method. - Original Message - From: Gé Weijers Sent: 05/14/12 11:31 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Support for Zscaler proxy... Connecting to an HTTPS server through a proxy uses the connect method, if your IT dept. even bothers to route HTTPS through Zscaler. -- Gé ___ 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] How can I determine if a repository has actually changed?
Any changes in configuration will not show-up in timeline. - Original Message - From: Leo Razoumov Sent: 03/22/12 02:54 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How can I determine if a repository has actually changed? On Wed, Mar 21, 2012 at 17:17, Stephan Beal sgb...@googlemail.com wrote: On Wed, Mar 21, 2012 at 8:40 PM, Ron Aaron r...@ronware.org wrote: So what I am looking for is a way to take a 'snapshot' of a repo, and determine if the new version of that repo is actually different, even though I may have done multiple pulls in between checks. Doesn't the timeline reveal if anything meaningful was changed? Could you not query the timeline (e.g. via scripting fossil json timeline...)? I think this is the winner. I cannot thing of any (non pathologically esoteric) cases when a repo changes but the last 20 commits stay the same. --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] Help finding download links. Was: SQLite and Windows Metro Style
Why not make links (with uuid=trunk) available via skin? - Original Message - From: Richard Hipp Sent: 03/16/12 07:39 PM To: fossil-users Subject: [fossil-users] Help finding download links. Was: SQLite and Windows Metro Style Email below, from the SQLite mailing list, demonstrates a common problem with the Fossil user interface: people who are not familiar with Fossil cannot easily find the tarball and zip-archive download links. They seem to be too well hidden. Any suggestions on how we might improve this? -- Forwarded message -- From: Richard Hipp d...@sqlite.org Date: Fri, Mar 16, 2012 at 10:00 AM Subject: Re: [sqlite] SQLite and Windows Metro Style To: General Discussion of SQLite Database sqlite-us...@sqlite.org On Fri, Mar 16, 2012 at 9:49 AM, Philipp Kursawe phil.kurs...@gmail.comwrote: Hello How can I download the current WinRT efforts and compile them myself into a WinRT component? Download the latest winRT code from http://www.sqlite.org/src/timeline?r=winrt All I see there is a checkin history. Clicking on files does give me files but no tarbar or something to download the winrt branch. Click to get to http://www.sqlite.org/src/info/cd70bc4b78 then look beside Other Links: and click on either Tarball or ZIP Archive. Phil ___ sqlite-users mailing list sqlite-us...@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users -- 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] feature proposal: explicitly public branches
Why not just productize limsync? - Original Message - From: Leo Razoumov Sent: 02/26/12 03:03 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] feature proposal: explicitly public branches On Sat, Feb 25, 2012 at 16:29, Christopher Berardi cbera...@natoufa.com wrote: On Sat, Feb 25, 2012 at 01:33:45PM -0500, Leo Razoumov wrote: Hi List, I am trying to accomplish a cascading work-flow Personal.fossil - Team.fossil - Public.fossil without history rewriting. I would like to entertain an idea of adding explicit public tag which will propagate in a way similar to private tag behavior. Push/Pull behavior will be modified to accomplish the following I might rather like to see the ability to specify which private branches get pushed and which don't. For example, using the --private option would default to all private branches, but add an additional argument that would either (or both) specify which branch(es) to push and which branch(es) to not push. Fine with me. Anything that allows to push/pull branches selectively is highly appreciated. --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] memory leak using fossil_getenv and fossil_mbcs_to_utf8
In ui or server commands, I guess atleast 1 instance of fossil keeps running,
listening to the port. If that functionality has memory leak, it needs a fix.
- Original Message -
From: Richard Hipp
Sent: 02/16/12 06:04 PM
To: slonik...@gmail.com, Fossil SCM user's discussion
Subject: Re: [fossil-users] memory leak using fossil_getenv and
fossil_mbcs_to_utf8
On Thu, Feb 16, 2012 at 6:37 AM, Leo Razoumov slonik...@gmail.com wrote:
Very recently fossil_getenv function was introduced as a wrapper
around standard getenv to get Unicode right.
In file.c:
/*
** Return the value of an environment variable as UTF8.
*/
char *fossil_getenv(const char *zName){
char *zValue = getenv(zName);
#ifdef _WIN32
if( zValue ) zValue = fossil_mbcs_to_utf8(zValue);
#endif
return zValue;
}
In Unix it returns pointer pointing into actual environment (should
not be modified or deallocated). In Windows, on the other hand,
fossil_mbcs_to_utf8 allocates memory via sqlite3_malloc. This memory
is not and cannot not be freed because of UNIX behavior.
It results in memory leak on Windows. Should one care?
No, one should not care.
Recall that the processing model for Fossil is that each invocation does
one operation then quits, allowing the operating system to clean up
afterwards. (The OS is your garbage collector.) It is important to free
memory that is allocated in a loop or that might be allocated multiple
times based on the size of your repository or the nature of your request.
However, for things like getenv() which are only called a small number of
times, a finite number of times, and which don't use much memory to begin
with, trying to keep track of when to free things merely increases the code
complexity and risks introducing new bugs.
--Leo--
___
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] fossil commit failure after merge
+1 I faced this a couple of days back and had to perform an incorrect commit. - Original Message - From: Leo Razoumov Sent: 02/10/12 03:39 AM To: Fossil SCM user's discussion Subject: [fossil-users] fossil commit failure after merge Hi List, I ran into a strange problem which results in fossil commit failure after a specific type of merge. I attached a self-contained shell script that reproduces the problem. Tested with trunk version of fossil on Linux. Here is the problem description. A fossil repository T.fossil contains two brunches trunk and next. In both branches there are two files foo and bar. At some point in development process I merge branch next into the trunk. The contents of the files are such that fossil merge next successfully auto-merges changes in bar but has merge conflicts in foo that has to be manually resolved. So far so good. $ fossil cha UPDATED_BY_MERGE bar EDITED foo The project's internal logic dictates that while fixing merge conflicts in foo I have to make some changes to bar. After any changes to bar fossil refuses to commit claiming that working checkout does not match what would have ended up in the repository. I think this behavior is incorrect, for it forces me to commit a broken state of the project. Please, run an attached shell script to reproduce the problem. --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] Retro side-by-side diffs
Same here. I like the colorful diff. But I would like to know (sorry if I missed) what's th eproblem with color sbs and what are we getting with retro sbs? - Altu - Original Message - From: Weber, Martin S Sent: 02/03/12 11:03 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Retro side-by-side diffs On 2012-02-03 12:31 , Remigiusz Modrzejewski l...@maxnet.org.pl wrote: I'm for color-coded. All of the reasons have already been listed in the thread. Same here. -Martin ___ 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] Now with color: Retro side-by-side diffs
+2
Liked both the diffs.
Are colors configurable from skin?
I used following CSS for bsdiff (I find bluish color better than yellow for
changed lines):
table.sbsdiff tr td.added {
background-color: rgb(220, 244, 220);
}
table.sbsdiff tr td.removed {
background-color: rgb(244, 220, 220);
}
table.sbsdiff tr td.changed {
background-color: rgb(220, 220, 244);
}
- Original Message -
From: Richard Hipp
Sent: 02/05/12 01:33 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Now with color: Retro side-by-side diffs
On Sat, Feb 4, 2012 at 2:26 PM, Martin Gagnon eme...@gmail.com wrote:
Nice.. Same kind of coloring on unified diff would be nice too..
Implemented before you even asked. See,
http://www.fossil-scm.org/fossil/ci/b57b035654?sbs=0 for example. Chrome
users, the CSS has changed again so be sure to reload 6 or 7 times.
--
Martin G.
Le 2012-02-04 à 14:14, Richard Hipp d...@sqlite.org a écrit :
A colorized version of the retro-sbsdiff branch is now on the main
website. An example:
http://www.sqlite.org/src/info/21695c3476
Suggestions for improvements to the CSS (colors and fonts) are welcomed.
On Fri, Feb 3, 2012 at 10:25 AM, Richard Hipp d...@sqlite.org wrote:
For some time now, the SQLite and Fossil websites have been running on
the retro-sbsdiff branch of Fossil. The retro-sbsdiff branch uses a
vastly simplified format for the side-by-side diffs that omits all of the
colors and decoration and provides plain-text output - essentially the same
output as you would get on the command-line using the -y flag. Example:
http://www.sqlite.org/src/info/21695c3476
I find the retro side-by-side diff to be much more readable, which is
why I am using it on the SQLite and Fossil websites, as well as on my
desktop. And I've heard no complaints from users about the retro sbsdiffs
on the website. But before I merge the retro-sbsdiff branch into trunk (and
hence purge the existing colorful sbs diff from the trunk) I thought I
would as for community feedback. Are there strong preferences one way or
another?
--
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
___
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] git vs fossil again (was: why you should not shun)
+1. Shunning a commit is a bad idea. But fossil will not differentiate type of content when shunning so not sure if it can prevent shunning a commit. - Original Message - From: Erlis Vidal Sent: 10/06/11 12:21 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] git vs fossil again (was: why you should not shun) I get the two points of view and I'm not saying one is right or wrong. Modifying the history versus keeping everything as indeed happens (the history after all) Yesterday I was confused because I though the shun was done in the big file, but indeed the shun was done in the commit also... will that modify the history? I got the feeling that shunning a commit will change the history... not sure about it, you tell me. If I'm working under the premisses that the history cannot be changed, is shunning a commit (in case it change the history) a valid operation? Maybe fossil shouldn't allow to shun a commit, just individual files, if you really want to shun all files in that commit, then fossil could allow that, (shun --all) but that shouldn't touch ever the commit artifact.. Regards, Erlis On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 5 Oct 2011 11:12:31 -0700 Mike Meyer m...@mired.org wrote: That sort of we don't need it, we don't need it mantra is a typical case of the famous Blub paradox. I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. First, note that there is a difference between rewriting history, which is what git supports, and deleting unwanted items, which is the request that started this. Correct. Second, that a feature doesn't affect you if you just don't use it is a fallacy. Sure, I think history should be sacrosanct, so I won't use rebase even if it's available. That doesn't stop others on the project (who don't agree with me) from using it . The only way to make sure that doesn't happen is to not have the feature available *at all*. I'm not entirely convinced. Look at the workflow used by the Git team: they maintain the set of well known branches, of which the only one, named pu (proposed updates), is allowed to be rebased and that's actually what happens with it each time the new release is made--it's cut from the master afresh. I mean, while every committer has `git rebase` at their disposal and knows how it works this does not mean they go off and break the repository with rebases. So your point is only really valid when the project is run by a bunch of idiots or complete newbies. Finally, having a feature that powerful available tends to cause the API to *not* include safe versions of common tasks that that dangerous feature handles. To see what I mean, take a look at mercurial, which shares the fossil philosophy, but provides a (disabled by default) rebase command. It has a number of commands (*not* disabled by default) for tasks that are handled in git using rebase. Unlike rebase, those commands are safe, in that mistakes with them can't wreck your repo the way a mistake with rebase can. It may not make a difference if you never make mistakes, but in that case you don't need rebase. Git handles it from the opposite direction by having the reflog. But I find this point to be valid, yes, safety nets are a must when it comes to handling precious data. BTW I'm a fan of `fossil undo` for that matter. Bottom line: while more features may imply more powerful, it doesn't imply better. Moot point. I really miss Git's index and `git add --patch` here. Is Fossil better than Git in this respect by not having those more features? Surely it completely is in the eye of the beholder. ___ 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] Timestamps should be in local time.
I assume if I de-select UTC, fossil will still use UTC in the database but show local time zone on timeline. Correct? - Original Message - From: Gé Weijers Sent: 08/21/11 09:36 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Timestamps should be in local time. On Sat, 20 Aug 2011, Vikrant Chaudhary wrote: Timestamps should be recorded in local timezone rather than in UTC. 1. It hurts eyes and brain to see the time in UTC and then calculate it in local time. 2. For forensics. I'll be able to know which timezone I was while committing that change. And we can always calculate the UTC time anyway. And by storing the time in local time we'll only gain the timezone information in history and loose nothing. Re: 1) as others have pointed out: this is configurable through the UI. Re: 2) If there is a convincing use case for your proposal I would store the time stamp in UTC and store the time zone separately (offset in minutes from UTC). Currently fossil can just use an SQL 'ORDER BY' clause to retrieve commits etc. in order, using local time stamps would make that more painful and definitly slower (you cannot create a simple index for that) 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] localauth question
Never mind. By adding a line with 'localauth' enabled admin options. - Original Message - From: Altu Faltu Sent: 08/18/11 10:25 AM To: fossil users Subject: [fossil-users] localauth question With fossil df9da91ba8 and localauth unset or set to 0, I observe that: 1. If I do 'fossil ui', I'm logged in and have admin options. 2. However, if I make access through apache/cgi via localhost, I'm not logged in. Is this expected? I see under Access Control Settings that 'from the fossil cgi if a line containing the word localauth appears in the CGI script'. Does the cgi setup require any additional command other than what is shown in the example here: http://www.fossil-scm.org/index.html/help?cmd=cgi for localauth to work? - Altu ___ 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] New features for merging
Me too like fossil because of simplicity of one file / less file clutter. Why can't versionable settings be treated like a wiki or ticket page and versioned inside the repository itself rather than as a file in work area? Then we can also see changes done to [versioned] settings right there in timeline! - Original Message - From: Mike Meyer Sent: 08/15/11 07:46 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] New features for merging On Sat, 13 Aug 2011 09:48:09 +0100 Ben Summers b...@fluffy.co.uk wrote: On 12 Aug 2011, at 22:39, Mike Meyer wrote: On Fri, Aug 12, 2011 at 1:28 PM, Ben Summers b...@fluffy.co.uk wrote: On 12 Aug 2011, at 20:44, Mike Meyer wrote: On Fri, Aug 12, 2011 at 12:33 PM, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/12/2011 07:10 PM, Joshua Paine wrote: On 8/12/2011 1:50 PM, altufaltu wrote: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. I thought this at first, too, but one file per setting makes it easier to manipulate with other tools, and it makes it easier to get an idea what happened from the commit log. Aye. My fossil extras .fossil-settings/ignore_glob brought a smile to my lips. I'm at worst neutral on all the other changes. This one bothers me. I consider fossil only having one file in the work space (__FOSSIL__) to be an advantages, because it makes working with the tree using standard unix commands that much easier. With most SCM software, I wind up doing some tree-level command, seeing the SCM files in the output, cursing, and then either running a SCM-provided command or a tweaked version of the unix command that deals with the SCM files. You can ignore this new feature, and everything will continue to work as it did before. The slightly clumsy name of versionable is to imply that they *can* be versioned, not that they inherently *are*. So these won't get copied around by push, pull, clone or sync? If they do, is there at least an easy way to turn them back into regular settings so I can delete them (and thus start the commit wars)? Settings aren't synced, which is the problem. When the values of the settings are stored in normal versioned files, they are, just as any other file. What I meant was that if you don't want to use this feature, you can still use settings in exactly the way you do in the current version. Yes, but my point is that my using setting exactly the way I do now isn't sufficient to keep my workspace from getting cluttered by these SCM files if someone turns them on in another clone of the repository. Whether or not they're actually used is immaterial. Let me be crystal clear - I have absolutely no objection to the features this change adds, and might well use them. My problem is with the extra clutter in my workspace. Maybe I was spoiled by 7 years of nothing but perforce (with *no* SCM files in the workspace) before being exposed to svn in '05, but fossil having so little clutter is one of it's attractions for me. I can understand wanting versioned settings, but does it need to go into the file system? Fossil versions other objects that aren't in the file system (wiki, tickets, etc). Is there some reason the same can't be done for versions? It would need to be part of checkin somehow, as wiki pages, tickets, etc, aren't in a branch. This would be adding another mechanism, when the whole point of this new feature is to give the option to move away from using an additional mechanism for these settings. I thought the whole point was to provide versioned settings? If all you want is not to have an additional mechanism, then just don't merge this feature into the trunk :-). OK, I wanted a mechanism which works. And it doesn't add a new concept into fossil, it just uses files, which everyone understands. If you insist on them being files, then there's not much point in further discussion. And having them in files means you can bring the full power of unix to bear on them (which, of course, is why I want them *out* of my workspace - as they are just noise when working with *my* files), which is hard to argue with. But - any chance of moving them into the wiki? The fossil wiki command would let you work with them with almost the same power at the command line (i.e. - fossil extras | fossil wiki import settings/ignore_glob should work), and in return you get to edit the settings via the wiki gui. Thanks, mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software
Re: [fossil-users] New features for merging
Ben, Thanks for providing improvements in fossil. I'd like to share 2 comments: 1. Versioned settings: I'd prefer having all settings in a single text file with name=value kind of one-setting-per-line format (although I don't mind a value spanning multiple lines for readability) rather than one file per setting. 2. Like many other users commented, I'd alo like relative path setting to be ON by default. I haven't tested your branch but would like to know if following would work: fossil commit -m comment ../parent.file ../parent/child.file local.file sub/file.name ... also for other commands like rm, add, etc. - Altu - Original Message - From: Ben Summers Sent: 08/12/11 04:17 PM To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] New features for merging Richard has kindly indicated he is probably willing to merge the changes in the ben-testing branch if the community has no objections, after being asked for any suggestions on improvements. I'd particularly like input on how these should be documented, and the names chosen for settings and command line options. I've added: * Versionable settings The inconvenience of using ignore-glob came up again a few days ago. When I started using fossil, I couldn't quite work out how to use them sensibly. So, I implemented versionable settings which take the values from versioned files in the repository. For ignore-glob, it gives you the rough equivalent of .gitignore files, although they're only specified at the root of the repository in a .fossil-settings directory. Documentation: - fossil help settings - Settings page in the web UI - http://fossil-scm.org/index.html/doc/ben-testing/www/settings.wiki (linked from home page) * SSL improvements I added support for SSL client certificates, for an extra level of authentication to the server. In addition, I added a setting to specify the trusted SSL root certificates. After implementing this, I was told of the existing jan-clientcert branch, and feel a bit silly for not noticing it earlier. This implementation, however, is much simpler and uses facilities built in to OpenSSL instead of doing certificate management inside fossil. As such, the impact on the fossil code is much less, but does require external programs to do the certificate management. With those external programs, it can do everything that the jan-clientcert branch does. Documentation: - fossil help settings (ssl-identity, ssl-ca-location) - fossil help clone (--ssl-identity option) - error message when trying to clone a repo which requires a client cert - http://fossil-scm.org/index.html/doc/ben-testing/www/ssl.wiki (linked from home page and existing server instructions page) * Relative pathname listings One of my projects requires that I work with the current working directory inside a subdirectory of the repository. I found it a bit confusing to list all filenames relative to the root of the repository, especially when copying and pasting output of 'extras' to 'add'. I've added a relative-paths setting. This defaults to 'off', to avoid changing the output for existing projects. Set this 'on' to list pathnames relative to the current working directory for status, changes and extras commands, with output similar to git's listings. You can also override this setting on the command line with the --rel-paths and --abs-paths options. Documentation: - fossil help settings (relative-paths) - fossil help status / changes / extras (--rel-paths --abs-paths options) Discussion on mailing list: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05066.html http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg05072.html (although options etc have changed at Richard's suggestion) * empty-dirs setting I moved to fossil from subversion, and my project expected the ability to version empty directories. I think this has come up a couple of times on the list. In an ideal world, I'd add the ability to version directories 'properly', but it would be quite a large change to the internals. Taking a pragmatic approach, I added a versionable empty-dirs setting which allows you to specify a list of directories which should exist after a checkout. Documentation: - fossil help settings Thanks for any feedback. Ben -- http://bens.me.uk/ ___ 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] _FOSSIL_ vs. .fos Was: New features for merging
+1 - Original Message - From: Joerg Sonnenberger Sent: 08/13/11 05:01 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] _FOSSIL_ vs. .fos Was: New features for merging On Fri, Aug 12, 2011 at 06:42:23PM -0400, Richard Hipp wrote: You know you can rename _FOSSIL_ as .fos, right? mv _FOSSIL_ .fos Should I make .fos the default? I think .fos is too random / short. .fossil would be fine as default on UNIX (if you can figure out how to mark _FOSSIL_ as hidden on Windows, that would be good too). Joerg ___ 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] Why do people create branches as a separate step? Was: Unable to sign manifest
It is more like a logical process. You want to work on something, create a branch, work on it and commit. If you have to create a branch when committing, you will have to remember if this is first commit in that branch or subsequent. You commandline will also be different for first commit that creates the branch - not good for scripting or for 3rd party GUIs - IDEs? - altu - Original Message - From: Richard Hipp Sent: 08/09/11 08:28 PM To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Why do people create branches as a separate step? Was: Unable to sign manifest On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com tpero...@compumation.com wrote: fossil branch new Test 5947928ba Change the subject: Please help me to understand why people want to create a new branch before adding changes to that branch, rather than just waiting until they check-in their edits? I'm not being sarcastic or critical here. A lot of people do this and I sincerely want to understand the motivation. The way I've *always* done things is: (1) ... edit files (2) fossil commit -branch new-branch But I see many people want to do a 4-step process: (1) fossil branch new new-branch (2) fossil update new-branch (3) ... edit files (4) fossil commit That seems like so much more trouble. What am I missing? Is it that people are unaware that they can make edits that are destined to go into a branch before that branch actually exists? Do I need to improve on the documentation? Or does creating the branch first, before making file edits, just fit most peoples mental model better? Are there some advantages to creating branches in advance that I am missing? Part of the motivation for this question is that, because I never use fossil branch new myself, there tend to be more bugs in that command than in the other commands that I use daily. If there is a good reason to do fossil branch new then maybe I'll start using it myself and those bugs will get fixed sooner. Or if not, maybe I'll deprecate fossil branch new - or at least print a warning and ask for confirmation: Creating branches ahead of check-ins is unnecessary. Are you sure you want to do this? (y/N) Please explain. 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
Re: [fossil-users] [OT] commit command seems to be slow
Ha, never thought there can be fun in this list! :D - Original Message - From: Remigiusz Modrzejewski Sent: 08/05/11 07:07 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] [OT] commit command seems to be slow On Aug 5, 2011, at 15:14 , Stephan Beal wrote: ++ So why not potato/cucumber? ;) My Comp-sci teacher back in the 80's always used the word broccoli for such cases. Heh, Broccoli is a name of some big project my team finished just before I joined ;) Kind regards, Remigiusz Modrzejewski ___ 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] commit command seems to be slow
Fossil is flexible here. yes/no, 1/0, on/off, true/false any of these can be used for binary settings. Some settings (like proxy) even can use real proxy address than on/off. very cool! - Original Message - From: Wes Freeman Sent: 08/04/11 09:32 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] commit command seems to be slow 2011/8/4 Lluís Batlle i Rossell virik...@gmail.com: On Thu, Aug 04, 2011 at 05:21:00PM +0200, Stephan Beal wrote: 2011/8/4 Lluís Batlle i Rossell virik...@gmail.com (btw, I never know what do I have to write to enable. 'on', '1', 'yes', ... and what to disable) Try 'fossil set' and use whatever it shows. 1 and 0 work for me. It shows whatever you set it to, or nothing. :) How about fossil help set. It shows the defaults. Wes ___ 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] Automatic branch color selection. Was: Question on short-lived branches in fossil
Never mind. I swapped ubg brbg - Original Message - From: Altu Faltu Sent: 07/23/11 12:01 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Automatic branch color selection. Was: Question on short-lived branches in fossil Why does the same branch (trunk) take different backgrounds? - Original Message - From: Richard Hipp Sent: 07/23/11 04:55 AM To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Automatic branch color selection. Was: Question on short-lived branches in fossil On Fri, Jul 22, 2011 at 5:32 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Jul 22, 2011 at 11:07 PM, Ross Berteig r...@cheshireeng.com wrote: For skins that are dark text on white background, then using the existing MD5 hash on the tag name, picking a convenient three; ... it would make an entertaining experiment, whether or not it turns out to be useful in practice. An experimental change to implement this is on the server. Add the brbg query parameter to the timeline method to have the background color set by branch name. Add ubg to have the background color set by user name. Examples: http://www.fossil-scm.org/fossil/timeline?n=200y=cibrbg http://www.fossil-scm.org/fossil/timeline?n=200y=ciubg I tried Ross's proposed color choosing algorithm but it didn't work out. So instead I used the hash to select a Hue in an HSV color space, held the S and V fixed, and mapped the result into RGB. The color chooser code is here, if you are interested: http://www.fossil-scm.org/fossil/artifact/506fc3a6b2808?ln=116,144 Feedback is encouraged. Remember this changes is experimental and might disappear at any moment! -- 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] The fossil service command
I'd say service is good. win-service may be appropriate since this command is valid only on Windows. However, I'd like to avoid use of hyphen (-) in commands. I hope this command is automatically disabled (via compiler or run-time) for non-windows platforms. - Original Message - From: Ron Wilson Sent: 07/19/11 04:03 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The fossil service command On Mon, Jul 18, 2011 at 4:52 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 18, 2011 at 10:51 PM, Richard Hipp d...@sqlite.org wrote: something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? i'd prefer win-service, but i don't use windows so i don't get a vote. win-service makes sense to me. I am in a mixed environment. or maybe: fossil M$ervice ;) *chuckle* ___ 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] History for a directory
bump... -Original Message- From: Remigiusz Modrzejewski l...@maxnet.org.pl To: fossil-users@lists.fossil-scm.org Sent: Fri, Apr 1, 2011 6:17 pm Subject: Re: [fossil-users] History for a directory On Apr 1, 2011, at 13:12 , Martin Gagnon wrote: On Tue, Mar 1, 2011 at 9:09 AM, Martin Gagnon eme...@gmail.com wrote: Right now, it's possible to have the history for a specific file (using web interface) when browsing the file section. It would be nice to be able to do the same for a directory. Is there some interest for such a feature (which I think would be very easy to add for someone good in SQL, might be similar query as what finfo use).I'm slightly interested - nice to have, not nice enough for /me/ to work on it ;)Kind regards,Remigiusz Modrzejewski___fossil-users mailing listfossil-users@lists.fossil-scm.orghttp://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] Fossil on Hammer Principle
It doesn't have ClearCase!!! OMG -Original Message- From: Stephen De Gabrielle stephen.degabrie...@acm.org To: fossil-users@lists.fossil-scm.org fossil-users@lists.fossil-scm.org Sent: Fri, Mar 25, 2011 1:59 am Subject: Re: [fossil-users] Fossil on Hammer Principle Cute. It seems pretty accurate. IMHOS.On Thursday, March 24, 2011, Alaric Snell-Pym ala...@snell-pym.org.uk wrote: Hello! Hammer Principle is a whimsical site where people can rank contentious things on various axes, and it then generates overall scores for stuff. They added version control systems lately, and Fossil's one of them: http://versioncontrol.hammerprinciple.com/ However, as of the time of writing, only two people have expressed opinions on Fossil (and I'm one of them). Let's fix that :-) Enjoy, ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users-- --Stephen De Gabriellestephen.degabrielle@acm.orgTelephone +44 (0)20 85670911Mobile+44 (0)79 85189045http://www.degabrielle.name/stephen__ _fossil-users mailing listfossil-users@lists.fossil-scm.orghttp://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] An annecdote on screwing up (and recovering) a broken fossil repo
Single fossil.exe, single repository.fossil and single _FOSSIL_. That's why I love fossil :) - Altu -Original Message- From: Stephan Beal sgb...@googlemail.com To: fossil-users fossil-users@lists.fossil-scm.org Sent: Thu, Dec 23, 2010 7:58 pm Subject: [fossil-users] An annecdote on screwing up (and recovering) a broken fossil repo Hello, fellow fossilers, A few minutes ago i made a horrible mistake in a fossil repo and felt compelled to post a minor warning/gotcha for other developers out there. The solution to the mistake also points out a nice side-effect of the single-file _FOSSIL_ metadata approach (as opposed to using subdirs for repo metadata). (To be clear, the problem here was all my fault, not fossil's.) i was doing some old-school-style refactoring, something like: ~ perl -i -pe 's|WHIO_ENABLE_ZLIB|WHIO_CONFIG_ENABLE_ZLIB|g' $(find . -type f | xargs grep -l WHIO_ENABLE_ZLIB) In english: that replaces WHIO_ENABLE_ZLIB which WHIO_CONFIG_ENABLE_ZLIB in all files under the current dir (including subdirs). After doing so i wanted to see what files had been modified: ~ fossil status fossil: not within an open checkout Doh! After a moment it was clear what i had done - a text replace in _FOSSIL_, which of course corrupted it. For a fossil repo, there is a trivial workaround: ~ mkdir foo ~ cd foo ~ fossil open /path/to/original.fossil ~ mv _FOSSIL_ .. ~ cd .. ~ rm -fr foo (By sheer cosmic coincidence, i didn't even lose my un-pushed wiki changes because i had exported them beforehand so that the wiki would be included in the search/replace operation.) On a Subversion repo, or most other system where SCM metadata is stored in multiple subdirectories, this recovery would have been a lot more difficult (and would have required online access to the repo). (Yeah, i've also screwed up such repos via this same mistake before.) So the lessons are: a) Don't screw up your _FOSSIL_ file. This is a no-brainer, obviously, but sometimes we act as if we have no brains and we do something like i demonstrated at the top of this post. b) If you do screw up _FOSSIL_, recovery is trivial. At most you'll lose any un-pushed wiki/ticket/etc changes. Happy fossiling! -- - stephan beal http://wanderinghorse.net/home/stephan/ ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] An annecdote on screwing up (and recovering) a broken fossil repo
You can use eclipse IDE to refactor C code. -Original Message- From: Stephan Beal sgb...@googlemail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Dec 23, 2010 10:24 pm Subject: Re: [fossil-users] An annecdote on screwing up (and recovering) a broken fossil repo On Thu, Dec 23, 2010 at 5:49 PM, Stephan Beal sgb...@googlemail.com wrote: Again, i don't consider this to be a fossil problem, but stupid user error. Another point: this problem was a side-effect of my own personal workflow, using an operation which has obvious risks of making unwanted changes (e.g. i didn't properly use \b in the perl expression to ensure unwanted expansions on other matching tokens). e.g. if i was fossiling Java code and had used a modern IDE to refactor the code, this would never have come up. (But i know no better C refactoring tools than perl and emacs.) i guess what i'm saying is: don't change fossil for this. i just thought the recovery was enlighteningly simple, and wanted to share it. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Errors during compile in Windows 7 x64
Hi Ross, I face this issue even on Win32 XP SP2. It used to build successfully before recent commit [e084092a07]. Were you successful to build it after above commit? - Altu -Original Message- From: Ross Berteig r...@cheshireeng.com To: fossil-users@lists.fossil-scm.org; fossil-users@lists.fossil-scm.org Sent: Thu, Dec 23, 2010 7:04 am Subject: Re: [fossil-users] Errors during compile in Windows 7 x64 At 04:29 PM 12/22/2010, Richard Hipp wrote: I spent a very frustrating morning on Monday, downloading mingw and trying to get the makefile to work on a new windows7 box I have sitting off to might right. It appears that getting the makefile to work on win7 will be very hard indeed. If anybody has any hints, I would like to hear them. At the moment, the only thing I can think to do is to completely rework the entire build process to not depend on standard unix tools like make and awk and sed since they just do not work or do not exist on mingw/windows7. This ought to work out of the box if you add MSYS to your MinGWinstallation. Alternatively, there are builds of most of thecommon *nix utilities available from the GnuWin32 project(gnuwin32.sourceforge.net). I know that they provide builds ofboth sed and awk. Assuming you use Gnu Make built natively forWindows (also available from GnuWin32), then it ought to bepossible to get it to build from a CMD prompt without the MSYSport of bash and friends. I have built fossil here under WinXPusing some combination of the above tricks, but that PC is nowretired and I haven't had a reason to build fossil myself since Ireplaced it with a new Win 7 Pro machine.If your Win 7 is either Professional or Ultimate (but not HomePremium) then another approach is to install Virtual PC and thehighly integrated XP Mode. That gets you a virtual machinerunning a fully licensed XP SP3. (With Home Premium, you canstill use Virtual PC, but you don't get an XP license to run init so you'd have to provide one separately.)This is a useful thing to do if you want and need to test thingsin 32-bit XP as well as under Win 7 64-bit, or if you have toolsthat cannot run in Win 7 for some obscure reason. If you had aknown to work build recipe for XP, then this might be an approach.I will take some time soon to work out what the build recipefor MinGW on Win7Pro 64-bit can be, and specifically whatpackages other than MinGW are required to get it to build. I'llreport back to the list if someone doesn't beat me to it.Ross Berteig r...@cheshireeng.comcheshire Engineering Corp. http://www.CheshireEng.com/___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] fossil set outside an open checkout
I might be mistaken. I always used that command from a checkout. -Original Message- From: Richard Hipp d...@sqlite.org To: fossil-users@lists.fossil-scm.org Sent: Tue, Dec 21, 2010 7:54 pm Subject: Re: [fossil-users] fossil set outside an open checkout On Tue, Dec 21, 2010 at 9:18 AM, altufa...@mail.com wrote: If I remember, I could do fossil set outside any open checkout to read / set global settings. Today I discovered that fossil set requires a repository or open checkout. Is this expected? I didn't know you could do fossil set outside of an open checkout ___ 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 listfossil-us...@lists.fossil-scm.orghttp://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] Errors during compile in Windows 7 x64
Me too get this error, compiling on XP (MinGW). Looks like one of the side effects of http://localhost/fossil/fossil/info/e084092a07. -Original Message- From: Arnel Legaspi jalespr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Tue, Dec 21, 2010 4:41 am Subject: [fossil-users] Errors during compile in Windows 7 x64 Hello,Compiling Fossil in 64-bit Windows 7 appears to stop after the makeheaders step. It produces the following error:Can't read input file .\wobj\add_.c;.\wobj\add.h // and so on...Checking the wobj folder, there are no files ending in *.h.I am using MinGW for this with GCC v4.5.1.There are instructions on the Fossil wiki regarding using Pelles-C instead of MinGW - should I try that instead?Thanks,Arnel___fossil -users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Hello. Anyone for source highlighting?
+1 -Original Message- From: pablo veliz pve...@viva.com.do To: fossil-users@lists.fossil-scm.org fossil-users@lists.fossil-scm.org Sent: Thu, Dec 16, 2010 8:07 pm Subject: Re: [fossil-users] Hello. Anyone for source highlighting? Since we are using a browser to see the code, why not use a client side library for syntax-highlighting like http://codemirror.net/ ?That way works in any platform, and can be extended for different languages.-Original Message-From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Martin SandifordSent: Monday, December 13, 2010 7:11 PMTo: fossil-us...@lists.fossil-scm.orgsubject: Re: [fossil-users] Hello. Anyone for source highlighting?I'm in favor. Not really sure what I need to do to help this to happen?Code review anyone?MartinOn 07/12/2010, at 8:40 PM, Gour wrote: On Mon, 8 Nov 2010 21:51:19 +1030 Martin == Martin Sandiford wrote: Martin Changes are on the experimental branch. It's been tested Martin reasonably well on MacOSX and Linux. I've implemented a Win32 Martin version as well, but this has really only had basic testing. Is there any chance that it ends applied to the upstream? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA ___ 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 listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi -bin/mailman/listinfo/fossil-users___ fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Hello. Anyone for source highlighting?
This is interesting. Where can I get consolidated recipe? - Altu -Original Message- From: Volodya Savastiouk, MSC volo...@io3.ca To: fossil-users@lists.fossil-scm.org Sent: Fri, Dec 17, 2010 12:13 am Subject: Re: [fossil-users] Hello. Anyone for source highlighting? Hi, I did mentioned it here a few days back, the source highlighting canwork with *no* changes to Fossil. I have it working for me on chiselapp.com. What will be great is if the html output can be configured to have more classes/div/id to be used in CSS. I'm not sure if it's ok to send a small screenshot here, but I'll try anyway. Here's how I see diif: Cheers, Volodya ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Cannot clone fossil
Thanks Venkat, That worked for me too - Altu -Original Message- From: Venkat Iyer ven...@comit.com To: fossil-users@lists.fossil-scm.org Sent: Sun, Nov 7, 2010 2:04 pm Subject: Re: [fossil-users] Cannot clone fossil What worked for me was cloning from www2.fossil-scm.org and then changing the url to point to www.fossil-scm.org. - Venkat -Original Message- From: altufa...@mail.com altufa...@mail.com Sent: Saturday, November 6, 2010 22:52:47 Subject: Re: [fossil-users] Cannot clone fossil Exactly the same... waiting for server in the first go... fossil-d0753799e4.exe clone http://www.fossil-scm.org/fossil fossil.fsl --proxy off Bytes Cards Artifacts Deltas Sent: 53 1 0 0 waiting for server...^C - Altu -Original Message- From: Richard Hipp d...@sqlite.org To: fossil-users@lists.fossil-scm.org Sent: Sun, Nov 7, 2010 1:56 am Subject: Re: [fossil-users] Cannot clone fossil On Sat, Nov 6, 2010 at 11:24 AM, altufa...@mail.com wrote: Still doesn't work for me... I'm sorry to hear that. It is working fine for me. Can you give additional information about what is going wrong? How do you know that it is not working? What error message is it giving you? - Altu -Original Message- From: Richard Hipp d...@sqlite.org To: fossil-users@lists.fossil-scm.org Sent: Sat, Nov 6, 2010 6:22 pm Subject: Re: [fossil-users] Cannot clone fossil Your work-around until I get 302-handling fixed is to use fossil clone http://www.fossil-scm.org/fossil myclone.fossil On Sat, Nov 6, 2010 at 2:04 AM, altufa...@mail.com wrote: I'm unable to clone fossil any more... ___ 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] Question about global settings
if it is, it sets the local config to whatever the global was. Can you check if this is true? I'm using latest version of fossil, which doesn't exhibit this. - Altu -Original Message- From: James Turner ja...@calminferno.net To: fossil-users@lists.fossil-scm.org Sent: Thu, Nov 4, 2010 8:05 am Subject: Re: [fossil-users] Question about global settings So looking through the source code, I can see why the autosync global doesn't work in my case. It would seem on repository creation, fossil checks to see if the global autosync setting is set, if it is, it sets the local config to whatever the global was. When a db_get is ran it checks the local config and only if it doesn't find a match does it check the global. Since I changed the global autosync setting after the fact, it doesn't get honored. So my question is, should the global config get checked before the local config? Or should local always win? I would think if after the fact I decided I want to turn autosync off globally I should be able to with out having to change autosync in each individual repository. Feel free to let me know if I've missed some obvious behavior. Thanks. ___ 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] Fossil enhancements: Please test
No reply to this question yet - sound that this option is risky! - Altu -Original Message- From: altufa...@mail.com To: fossil-users@lists.fossil-scm.org Sent: Wed, Oct 20, 2010 9:58 am Subject: Re: [fossil-users] Fossil enhancements: Please test Hi Richard, These changes are interesting. fossil setting repo-cksum off If I use this setting on local checkouts and let's assume for some reasons that a commit damages the local database. If I don't have repo-cksum disabled on the remote repository (assume on http), will I get an error message when I push? I want to make sure that my remote repository never gets corrupted. That way, I can have this setting disabled on local database for faster commits and then once I push, I can know that something went wrong. Then, I can try to recover my loss of work using current checked-out code and a corruption-free remote repository. - Altu ___ 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] Managing file attributes of repository files
fossil chmod is a good idea! - Altu -Original Message- From: Joshua Paine jos...@letterblock.com To: fossil-users@lists.fossil-scm.org Sent: Tue, Oct 19, 2010 8:04 pm Subject: Re: [fossil-users] Managing file attributes of repository files On 10/19/2010 10:00 AM, Richard Hipp wrote: The main complication is getting the permissions to be transmitted reliably through a windows checkout. (Why is it always windows that gives trouble?)Going between *nix and windows systems, it seems every file windows touches gets an execute bit set. SVN handles this by having an svn:executable flag you can set on files. When checked out on a system with *nix-like permissions, the file gets the execute bit flipped, otherwise not.I like fossil keeping track of my actual permissions, but maybe add a `fossil chmod [+-]x filename` for windows only? On windows, the execute bit would be off on new files, untouched on modified files unless they've been fossil chmod'ed.-- Joshua PaineLetterBlock: Web applications built with joyhttp://letterblock.com/301-576-1920___ fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Fossil enhancements: Please test
Hi Richard, These changes are interesting. fossil setting repo-cksum off If I use this setting on local checkouts and let's assume for some reasons that a commit damages the local database. If I don't have repo-cksum disabled on the remote repository (assume on http), will I get an error message when I push? I want to make sure that my remote repository never gets corrupted. That way, I can have this setting disabled on local database for faster commits and then once I push, I can know that something went wrong. Then, I can try to recover my loss of work using current checked-out code and a corruption-free remote repository. - Altu ___ 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] fossil rebase
Well, you have custom changes (A, B, C) in a branch and you want to keep up with latest changes happening in trunk - at frequent intervals. What rebase does is it applies your changes A, B C to new head (G) with a knowledge of everything that has happened between E G. If any of A, B or C was pulled in to the trunk, that change will be removed automatically. - Altu -Original Message- From: Eric e...@deptj.eu To: fossil-users@lists.fossil-scm.org Sent: Thu, Jun 24, 2010 12:00 pm Subject: Re: [fossil-users] fossil rebase Git rebase help has a very good graphic to explain what it does: Assume the following history exists and the current branch is topic: A---B---C topic / D---E---F---G master From this point, the result of either of the following commands: git rebase master git rebase master topic would be: A'--B'--C' topic / D---E---F---G master Here, git forgets versions A, B C if they are not published (tagged). I agree we don't want fossil to forget anything. However, if fossil can do following, that would be very helpful: A---B---C topic/ / A'--B'--C' (new name) / / D---E---F---G trunk - AltuBut why would anyone want to do that?E.___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] fossil rebase
I'm not sure. Is there really no difference? - Altu -Original Message- From: Michael Richter ttmrich...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jun 24, 2010 4:23 pm Subject: Re: [fossil-users] fossil rebase What does this do that fossil merge trunk from my branch in ttmrichter doesn't do? On 24 June 2010 16:31, altufa...@mail.com wrote: Well, you have custom changes (A, B, C) in a branch and you want to keep up with latest changes happening in trunk - at frequent intervals. What rebase does is it applies your changes A, B C to new head (G) with a knowledge of everything that has happened between E G. If any of A, B or C was pulled in to the trunk, that change will be removed automatically. - Altu -Original Message- From: Eric e...@deptj.eu To: fossil-users@lists.fossil-scm.org Sent: Thu, Jun 24, 2010 12:00 pm Subject: Re: [fossil-users] fossil rebase Git rebase help has a very good graphic to explain what it does: Assume the following history exists and the current branch is topic: A---B---C topic / D---E---F---G master From this point, the result of either of the following commands: git rebase master git rebase master topic would be: A'--B'--C' topic / D---E---F---G master Here, git forgets versions A, B C if they are not published (tagged). I agree we don't want fossil to forget anything. However, if fossil can do following, that would be very helpful: A---B---C topic / / A'--B'--C' (new name) / / D---E---F---G trunk - AltuBut why would anyone want to do that?E.___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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 -- Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot. --Sergey Brin, demonstrating the emptiness of the don't be evil mantra. ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] fossil rebase
Well, my understanding of rebase has changed since then, due to the same problem we faced. Git 'forgets' unpublished versions when doing rebase (but it need not - I may still be wrong here). I'm sure if fossil implements rebase, it will not forget old versions. What I'm interested in is the 'feature' of rebase where it can re-apply changes to a new a new head. The result may be in a new branch. - Altu -Original Message- From: Eric e...@deptj.eu To: fossil-users@lists.fossil-scm.org Sent: Wed, Jun 23, 2010 12:27 pm Subject: Re: [fossil-users] fossil rebase Hi, Is there a rebase feature in fossil that is similar to git rebase? If not, is it planned? - AltuAnd what is different sincehttp://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg017 89.html?Eric___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Windows build broken?
Hi DRH,
I can build fossil from trunk now.
However, there seems some issue with date/time. It shows incorrect date:
$ rm test.fsl
$ ./fossil new test.fsl
project-id: 6e13be383106646451d79a5eae4f731c84d22135
server-id: f0202d8c43fc11569996c45150aca4740ffd49c6
admin-user: altufaltu (initial password is df)
$ ./fossil timeline -R test.fsl
=== 5695-10-01 ===-- incorrect
02:47:22 [27672aa945] initial empty check-in (user: a0756885 tags:
trunk)
$ ./fossil version
This is fossil version [d778ffea81] 2010-06-23 13:30:32 UTC
Older version works well:
$ rm test.fsl
$ ./fossil new test.fsl
project-id: 8c9e5b041a9dceb16117a8bfc876f1d0f4b18190
server-id: c1b0500b000a2f7356065962422c5f4500e6ea4c
admin-user: altufaltu (initial password is b52440)
$ ./fossil timeline -R test.fsl
=== 2010-06-23 ===
14:40:32 [4a09f9f5b6] initial empty check-in (user: a0756885 tags:
trunk)
$ ./fossil version
This is fossil version [15b293259d] 2010-06-11 12:02:59 UTC
-Original Message-
From: Richard Hipp d...@sqlite.org
To: fossil-users@lists.fossil-scm.org
Sent: Wed, Jun 23, 2010 5:04 pm
Subject: Re: [fossil-users] Windows build broken?
On Wed, Jun 23, 2010 at 7:28 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Jun 23, 2010 at 3:44 AM, altufa...@mail.com wrote:
I'm trying to build 953d293c32 version of fossil for Windows, which
seems broken:
gcc -g -O2 -o makeheaders .\\src\\makeheaders.c
awk { printf \#define MANIFEST_UUID \\\%%sn\, $1}
.\\src\\..\\manifest.uuid VERSION.h
gawk: { printf #define MANIFEST_UUID \%%s\\n, }
gawk: ^ syntax error
gawk: cmd. line:1: { printf #define MANIFEST_UUID \%%s\\n, }
gawk: cmd. line:1: ^
unexpected newline or end of string
make: *** [VERSION.h] Error 1
The last change to that part of the makefile was in 2007. Are you
saying this used to work for you but it suddenly stopped working? Have
you changed your build environment?
At the time I wrote the paragraph above, I had not yet seen last nights
check-in from Mr. Morgat. That check-in does indeed break the build,
and on unix too. So it has been moved into a branch. Please build off
of the trunk and you should be OK.
- Altu
___
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
--
-
D. Richard Hipp
d...@sqlite.org
___fossil-users mailing
listfossil-us...@lists.fossil-scm.orghttp://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] fossil rebase
Hi, Is there a rebase feature in fossil that is similar to git rebase? If not, is it planned? - Altu ___ 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] Using ticket system from command line
HTML is complete, We agree. But then why these special formatting rules, which are very basic and too incomplete? http://fossil-scm.org/index.html/wiki_rules It will be preferred if Wiki pages are instead stored as .html files and not use any non-HTML formats. - Altu -Original Message- From: Richard Hipp d...@sqlite.org To: fossil-users@lists.fossil-scm.org Sent: Sat, May 15, 2010 7:18 pm Subject: Re: [fossil-users] Using ticket system from command line On Sat, May 15, 2010 at 8:23 AM, Gour g...@gour-nitai.com wrote: On Sat, 15 May 2010 07:11:35 -0400 Richard == Richard Hipp wrote: Dear Richard, Richard HTML is not complete enough? What do you want to do (or for Richard that matter what does any other wiki system do) that you can't Richard do (in a more standard way, I should add) with HTML? it is not point that HTML is not complete, but it is simply too cumbersome to write documentation in HTML. So it really comes down to a matter of personal preference. You say HTML is cumbersome. I say that Markdown, etc. are arbitrary and cumbersome. Different people have different ideas. And yet, by virtue of supporting HTML, the wiki in Fossil is both standard and complete, for reasonable meanings of those words. What you really mean to say is that the fossil wiki does not suit your tastes in wiki and you would prefer something different. It's an emacs versus vi thing. btw, what do you think about: http://www.fossil-scm.org/index.html/tktview?name=3e3018e96f ? Ticket change histories can be seen by following the links in the submenu bar at the top of the ticket display. Example: http://www.fossil-scm.org/index.html/tkthistory/49929a3557 http://www.fossil-scm.org/index.html/tkttimeline?name=49929a3557 -- - D. Richard Hipp d...@sqlite.org ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Fossil GUI for local source tree operations
Mercurial has a whole subsystem (mq) to manage unpublished patches. Git implements 'rebase', and allows you to move unpublished commits forward. This is dangerous and we have faced issues when we used commit ids from a git repository managed by another team. After few months, the commit ids we used in our scripts were no longer in the repository and we could not reproduce historical packages (just a couple of months old). I assume fossil will not encourage such features. There is a feature called 'shunning' that can be used for the third use case. - Altu -Original Message- From: Gé Weijers g...@weijers.org To: e...@deptj.eu; fossil-users@lists.fossil-scm.org Sent: Sun, Apr 4, 2010 4:47 am Subject: Re: [fossil-users] Fossil GUI for local source tree operations On Thu, 1 Apr 2010, Eric wrote: And that is the way SCM should be - _no_ opportunity to rewrite history.There are arguments for allowing some editing in history:- 'rebasing' commits allows you to keep a linear flow the the commits in a repo which makes things easier to follow. Mercurial has a whole subsystem (mq) to manage unpublished patches. Git implements 'rebase', and allows you to move unpublished commits forward.- abandoned branches just clutter up the repo, and it would be nice if they would not clutter up the branch name space forever.- some clueless soul can commit copyrighted material to your repo, and when you find out three years later because of a cease-and-desist letter you _need_ to edit history. The FreeBSD project did not go with Mercurial for this exact reason, but stuck to SVN because of previous experience. If that ever happens to the Linux kernel Git tree___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Fossil GUI for local source tree operations
I expected e.g. fossil changes to give me my current directory changes only. This is indeed a reasonable requirement. When working inside a checkout repository, all local commands should operate within working directory. - Altu -Original Message- From: Andy Reynolds a...@andix.co.uk To: fossil-users@lists.fossil-scm.org Sent: Wed, Mar 31, 2010 6:55 pm Subject: [fossil-users] Fossil GUI for local source tree operations I understand the rationale for the command line interface, of course. I am very comfortable using the command line (I always have at least one dos-box open). But sometimes you get a list of files e.g. fossil changes and for some of those files you would like to see the diffs - it's just easier to click. I envisage a seperate application just shelling out to the fossil binary which would do the real work. The situation is seems to be made worse by e.g. fossil reporting on all files in the source tree. I expected e.g. fossil changes to give me my current directory changes only. If I have a lot of files out and there are many changes then fossil diff blatts a lot of stuff. I still love fossil though! andy ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Fossil, first impressions
Hi Terry, Fossil has many good features that made me look at, contribute to and use it as personal VCS. However, fossil is created and maintained out of personal interest. It does not intent to become a next-gen DVCS system replacing git or others. The idea is: If you like it, use it. - Altu -Original Message- From: shards2...@yahoo.com To: Fossil fossil-users@lists.fossil-scm.org Sent: Fri, Feb 19, 2010 5:30 am Subject: [fossil-users] Fossil, first impressions I really liked trying out Fossil and it may become my personal vcs - the integrated wiki and ticket system are great and I use RamDebugger once in awhile, too - but I was initially evaluating it for work use, where our Subversion setup is turning into a giant space hog. I have a (growing) repository that is about 2 gigs checked out, 1 gig exported and the initial import into Fossil rocked because it was only about 250 megs. However, we need partial checkout ability and Fossil just recreates the whole exported repo when it is opened, thus defeating one selling point of finding a tool that uses less space. (It would save some server space, just not enough to justify introducing a whole new tool and it would actually force the programmers to use more disk space as near as I can tell - and mine isn't the only repo they use.) Even though I am the department support admin, I can't break the repo up since we have multiple projects under the trunk, tags, branches default layout and Subversion is administered by the server teams, which limits options there - like implementing SVK to make Subversion usable. The other feature I was looking at was the tagging. The engineers I work for are unhappy with SVN because they are being forced on to it from Clearcase, and they really miss the ability to label individual files (most of you probably know that SVN operates at the folder level - we had hopes that the new change set capability would be an alternative but it wasn't). I like how Fossil does leaves and branching but again the issue of no lite working copy, or partial checkouts is a deal breaker. While space is a big concern, keeping users out of some projects is even more important. So the search continues. Bazaar comes close but it's been too unstable on Windows every time I've tried it, git on Windows - well, enough said there, it was pretty painful when I tested it 6 months ago. Most of the open source version control systems I have tested say up front that they are built on the initial developers needs. As nice as Fossil is, I was disappointed that it isn't any different in that respect. But I'll keep an eye on the open Feature Requests (for partial co) to see if that changes. If I've overlooked any obvious workarounds while trying it out, please let me know. -- Terry ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] fossil new --date-override issue
Hi, It seems --date-override doesn't work correctly with fossil new, which is required for importing files from other repositories: $ fossil new test.fsl -A test --date-override 2010-01-01 UTC project-id: 05468b497577aa00211a76732a997723fb5a8acf server-id: 23567149953dd056df1d40062d214826895c9dae admin-user: test (initial password is 5a4f69) $ fossil timeline -R test.fsl $ The timelime shows no entries in second case. I'm unable to file ticket through proxy server as public IP changes heavily (even upper 16 bits) :( - Altu ___ 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] Graphical display of fork/merge actions in timeline
Graphical display doesn't show up on timelines for a branch: http://fossil-scm.org/index.html/timeline?t=ssl - Altu -Original Message- From: Clark Christensen cdcmi...@yahoo.com To: fossil-users@lists.fossil-scm.org Sent: Tue, Feb 9, 2010 3:47 am Subject: Re: [fossil-users] Graphical display of fork/merge actions in timeline FWIW, IE6 on XP, well, not so good. The boxes appear to be shifted down to align with the second line of text in the notes.Personally, I don't care about IE6, but it _is_ out there in large numbers. If it were up to me, I would disable the graphical display for IE6 with a simple browser sniff.Also, IE supports conditional comments (blocks of code that can be parsed/rendered depending on browser version). Might something like that be useful here?http://msdn.microsoft.com/en-us/library/ms537512(VS.85).aspx -Clark- Original Message From: D. Richard Hipp d...@hwaci.comTo: fossil-us...@lists.fossil-scm.orgsent: Mon, February 8, 2010 10:58:11 AMSubject: Re: [fossil-users] Graphical display of fork/merge actions in timelineOn Feb 8, 2010, at 1:41 PM, verizon wrote: Looking at it with Firefox 3.6 and Safari 4.0.4 (on OS X 10.6.2) I don't see any difference in the presentation. vertical and horizontal alignment appear identical on both browsers. --jimTnx, Jim; I fixed the Safari thing. And I fixed it so that the graph regenerates when you resize the browser. (Same fix, really.)IE is still given trouble, of course... On 8 Feb, 2010, at 13:23, Brett Schwarz wrote: On Mon, Feb 8, 2010 at 9:28 AM, Jeremy Cowgar jer...@cowgar.com wrote: So the updated score is: * Firefox, Opera, Chrome and Konqueror all work * IE does not work at all (at least versions 6 and 8, so we can *assume* 7 as well) * Safari has some issues I have IE 8. I got it to work by changing the Document Mode to IE8 Standards. There's probably someway around this programmable...I just haven't looked yet... ___ 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-usersD. Richard hipp...@hwaci.com___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Interesting use for Fossil: notes
Well, I also use fossil for file copy across my office laptop / home computer. One is with domain login, other with no domain and many times windows copy just doesn't work... may be because of firewall or some security app. But anyway, fossil works better as optimized / compressed file copy and I get version control for free! - Altu -Original Message- From: Stephen De Gabrielle stephen.degabrie...@acm.org To: fossil-users@lists.fossil-scm.org Sent: Sun, Jan 24, 2010 9:02 pm Subject: Re: [fossil-users] Interesting use for Fossil: notes Agreed, it probably counts as the easiest issue/bug tracker to setupin the universe, despite the TCL-like embedded language.StephenOn Sunday, January 24, 2010, Ron Aaron r...@ronware.org wrote: Fossil isn't only good for source-control! I just set it up as a server on my local machine (running off inetd, but you could also just run it with 'fossil server'). Added a shortcut in Firefox to point to http://localhost:3/ (where I have the server running) and voila! a perfect note-taking application ... which I can also easily back up to another site if I want. This is really cool stuff -- thank you, DRH! -- For privacy, my GPG key signature is: AD29415D-- --Stephen De gabriellestephen.degabrie...@acm.orgtelephone +44 (0)20 85670911Mobile+44 (0)79 85189045http://www.degabrielle.name/stephen___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] https doesn't work through proxy?
$ fossil open ../fossil/fossil.fsl ssl $ make $ ./fossil version This is fossil version [652f20ef9c] 2010-01-21 22:03:24 UTC $ ./fossil set proxy wwwproxy:80 $ ./fossil clone http://fossil-scm.org no-ssl.fsl Bytes Cards Artifacts Deltas Send: 49 1 0 0 Received: 287173 6242 0 0 Send: 10025225 0 0 ^c $ ./fossil clone https://fossil-scm.org ssl.fsl Bytes Cards Artifacts Deltas Send: 49 1 0 0 ERROR. server says: 504 Gateway Timeout Send: 619 24 0 0 ^c Does fossil use proxy server for https URLs? Do I have to manually change any file (on top of ssl branch) to make fossil work with https:// URLs? - Altu ___ 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] https doesn't work through proxy?
Hi, You tried with https:// or http://? http:// works well. - Altu -Original Message- From: paolo lulli plu...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Fri, Jan 22, 2010 7:23 pm Subject: Re: [fossil-users] https doesn't work through proxy? It happened to me also not to be able to get a HTTP clone via proxy.I'm not sure, but everything went ok simply giving:fossil clone http://fossil-scm.org no-ssl.fsl --proxy wwwproxy:80Without prior setting the 'proxy' var, nor exporting the http_proxyone. Maybe a bug on the proxy code ?Hope this could be of some help.Regards,Paolo Lulli2010/1/22 altufa...@mail.com: $ fossil open ../fossil/fossil.fsl ssl $ make $ ./fossil version This is fossil version [652f20ef9c] 2010-01-21 22:03:24 UTC $ ./fossil set proxy wwwproxy:80 $ ./fossil clone http://fossil-scm.org no-ssl.fsl Bytes Cards Artifacts Deltas Send: 49 1 0 0 Received: 287173 6242 0 0 Send: 10025225 0 0 ^c $ ./fossil clone https://fossil-scm.org ssl.fsl Bytes Cards Artifacts Deltas Send: 49 1 0 0 ERROR. server says: 504 Gateway Timeout Send: 619 24 0 0 ^c Does fossil use proxy server for https URLs? Do I have to manually change any file (on top of ssl branch) to make fossil work with https:// URLs? - Altu ___ 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 listfossil-us...@lists.fossil-scm.orghttp://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] https doesn't work through proxy?
Well, In my office all communication goes through same http proxy, including https. I guess they do pass-thru somehow. - Altu -Original Message- From: D. Richard Hipp d...@hwaci.com To: fossil-users@lists.fossil-scm.org Sent: Fri, Jan 22, 2010 9:02 pm Subject: Re: [fossil-users] https doesn't work through proxy? HTTPS by its very nature cannot use a proxy. It must go direct.I should probably enhance Fossil so that it automatically bypasses the proxy when using HTTPS. Until then, you can use the --proxy off command-line option to disable the proxy when using HTTPS.D. Richard hipp...@hwaci.com___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] https doesn't work through proxy?
As I said, it works in pass-thru mode. here are send/recieve dumps for following transaction: $ export https_proxy=localhost:8080 $ wget https://fossil-scm.org --2010-01-22 21:50:46-- https://fossil-scm.org/ Resolving localhost... 127.0.0.1 Connecting to localhost|127.0.0.1|:8080... connected. ERROR: cannot verify fossil-scm.org's certificate, issued by `/C=US/ST=North Carolina/L=Charlotte/O=SQLite.org': Self-signed certificate encountered. ERROR: certificate common name `' doesn't match requested host name `fossil-scm.org'. To connect to fossil-scm.org insecurely, use `--no-check-certificate'. Unable to establish SSL connection. - Altu -Original Message- From: D. Richard Hipp d...@hwaci.com To: fossil-users@lists.fossil-scm.org Sent: Fri, Jan 22, 2010 9:45 pm Subject: Re: [fossil-users] https doesn't work through proxy? On Jan 22, 2010, at 10:58 AM, altufa...@mail.com wrote: Well, In my office all communication goes through same http proxy, including https. I guess they do pass-thru somehow.Think about it. With HTTPS, only the two endpoints are able to read the content of the transmission. How can the proxy get involved? If the proxy could come into play, that would mean that HTTPS was vulnerable to a man-in-the-middle attack - it would be a serious weakness of HTTPS. - Altu -Original Message- From: D. Richard Hipp d...@hwaci.com To: fossil-users@lists.fossil-scm.org Sent: Fri, Jan 22, 2010 9:02 pm Subject: Re: [fossil-users] https doesn't work through proxy? HTTPS by its very nature cannot use a proxy. It must go direct. I should probably enhance Fossil so that it automatically bypasses the proxy when using HTTPS. Until then, you can use the --proxy off command-line option to disable the proxy when using HTTPS. D. Richard Hipp d...@hwaci.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-usersD. Richard hipp...@hwaci.com___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users send.bin Description: Binary data recv.bin 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] Add files recursively?
Wait... read this: C:\md repo C:\cd repo C:\repofossil new actual.fossil blah... C:\repocd .. C:\md waA C:\cd waA C:\waAfossil open ..\repo\actual.fossil C:\waAcd .. C:\md waB C:\cd waB C:\waBfossil open ..\repo\actual.fossil C:\waBcd .. C:\ There are only three files in waA and waB, which will come down to 1 when DRH commits the change. waA and waB are not related at all, other than the fact that they share (push/pull) same repository (C:\repo\actual.fossil). ... and, fossil server c:\repo\actual.fossil will give you a working fossil server! Try fossil ui c:\repo\actual.fossil if that makes it easy. - Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 4:13 pm Subject: Re: [fossil-users] Add files recursively? Michael Richter wrote: 1) I don't see how one file is better than one directory with one file. One is two entities to keep track of (one directory, one file) and one is a single entity to keep track of (one file). Seems pretty obvious to me.You won't be surprised to hear that I differ. When I use darcs I don't think about which files are inside '_darcs/' but fossil forces me to think about four files and pollutes my root directory. 2) But the truth is that there *are* other files. You can move them to other directories, but they still exist, and arguably it is worse to have the other files spread out instead of having them together. You are not understanding the whole point of this. *You are not _intended_ to put your repository file in the same directory as your project.* The repository is a single database which is shared by all checked-out instances of it.Ok, but (1) this is not in the docs and (2) it doesn't solve the more files to keep track of issue. Other SCMs manage to work without asking me to have a separate file in some directory outside my directory tree. It seems odd that fossil would need to add that extra little bit of complexity. Consider the case of hg or darcs or some other such distributed system which conflates the repository and the working set. I'm working on a project, so I clone a remote repository into a local directory. I make changes to feature A. While I'm working on A, I get a high-priority request to work on feature B. Either I clone the remote repository again (needs network, needs time, hits the remote server harder in a large project, wastes space as the repository itself is recopied, etc.) or I clone my local copy in A (which just wastes the space).If don't see how fossil makes you waste a lot less space. You still have two working trees. You avoid duplicating the database, but I would assume that that's not a very large file to begin with. Especially on modern hard disks. I have a Darcs project that has been going on for a while. The _darcs directory is 13MB and my hard disk has space for 160GB. It never crossed my mind to think about wasting 0.008% of my hard disk. I can get back a lot more space by removing a program I don't use. Let's say we took the second option. While I'm working in B, I finish my work in A. I push my changes and delete A ... and WHOOPS! I just screwed up B, didn't I?Why would that screw up B? If making a little branch like that screws up the SCM then the SCM sucks. The whole reasons why we have SCMs so to allow concurrent development. B is expecting A as an uplink which is now gone because the distinction between the working set and the repository is fuzzy.If your SCM works like that, then it's the SCM's fault. It's stupid. Take Darcs, Mercurial or Bazaar. Create a repository, then pull from it to make A, then pull from that to make B, then delete A, and there is no problem. Why would there be? A is a branch, B is a branch, there is no good reason why B needs A. I can reseat B to point to another copy of the repository (and hope that that repository doesnt' have changes which clash with the changes I made in A and in B) but I think anybody can see that this is not a particularly good solution.I think it is fixing the wrong problem. B should not have to point to one specific branch for it to work. If this is how fossil works, to me that's just one more reason not to use fossil. As I said, the whole point of SCMs is to allow concurrent development and this is more true for distributed SCMs. I should be able to make branches nilly willy without the whole thing breaking due to some weird DAG that the SCM needs. I don't have to think about these things if I use Darcs, Bazaar or Mercurial. Fossil keeps the concept of the repository and the working set distinct.Btw, AFAIK the only SCM that joins these concepts is Darcs.Anyways, the things you've said have only scared me off from using fossil. I didn't know that fossil would require branches to point to other branches in some sort of DAG. b) Change a configuration to get rid of two files, then
Re: [fossil-users] Add files recursively?
As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist. You made very good points. Let's talk once you understand how fossil actually works...- Altu -Original Message- From: Daniel Carrera dcarr...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Jan 21, 2010 10:11 pm Subject: Re: [fossil-users] Add files recursively? Twylite wrote: Again, this has absolutely nothing to do with branches. I don't know where you're getting that idea from.In other SCMs, if I do this:$ cd B$ darcs init$ darcs pull ../AI am creating a new branch B, separate, and independent of A. Ditto for Hg, Git and Bazaar. As I said earlier, I think you misunderstand how the SCMs you criticize actually work. So you are seeing problems that don't exist.Daniel.___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Fossil HTTPS Support
I'd also like to switch to https. I don't understand dependencies, etc very much. Does anyone have recipe to build it with https support on Windows? - Altu -Original Message- From: p...@planet.nl To: fossil-users@lists.fossil-scm.org Sent: Tue, Jan 12, 2010 5:28 pm Subject: Re: [fossil-users] Fossil HTTPS Support If it gets added to trunk, could the binding to libcrypto and libopenssl please be optional? I mean rather than compiling with a dependency on those libs, add code to dynamically load these libraries and disable https: support if they cannot be found. Those libraries are available standard on linux boxes, but not on windows. Not sure about FreeBSD OS X. The mingw dll's are about 1 MB in size if I remember well. Also, older posix systems may not have the right version available. An alternative would be to consider something like the cyassl library, a 150K binary, which could be made a co-build, next to Fossil. How would SSL support work in the case where fossil is hosted at a cheapo ISP and the cgi setup is used to serve requests? Paul From: fossil-users-boun...@lists.fossil-scm.org on behalf of Ron Aaron Sent: Tue 1/12/2010 7:12 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Fossil HTTPS Support On Tuesday 12 January 2010 08:09:21 George King wrote: Hi list, Given the recent security discussion, I would like to inquire about the current state of HTTPS support Unless there are compelling reasons not to, could these additions be merged into trunk? I would also like this. No need for it to be a default -- if the repo address begins 'https', then use that ... otherwise, don't. -- Sending me something private? Use my GPG public key: AD29415D ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] HTTPS implementation
Hi Dmitry, I built fossil with https support on Linux but it keeps asking me about the certificate even if I accept with 'a' (always). I tried merging trunk to ssl branch to see if it resolves the problem but it persists. If I keep saying 'a' to certificate prompts, I can clone successfully. But then if I sync, it again prompts me and then prints the REPLACE INTO statement in console, followed by a message to run fossil all rebuild, which also does not help. Please help. This is how I built it: fossil open fossil.fsl ssl vi Makefile (to enable FOSSIL_ENABLE_SSL=1) make This is fossil version [d92945e5da] 2009-11-09 21:22:32 UTC - Altu -Original Message- From: Dmitry Chestnykh dch...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Nov 5, 2009 7:07 am Subject: Re: [fossil-users] HTTPS implementation Okay, here's how I currently implemented it.Everything SSL is in http_ssl.c, which has a similar interface to http_socket.c, and http_transport.c calls these functions.When a user connects to https server, s/he's presented with Unknown SSL certificate prompt, which prints some values from certificate, for example:Unknown SSL certificate: countryName = RU stateOrProvinceName = Some-State organizationName = Coding Robots commonName= codingrobots.com emailAddress = x...@xxx.comissued By:...and asks him to decline, accept or always accept this certificate. (Usually, when using HTTPS, SSL certificates signed by trusted root CAs are automatically accepted, however this requires keeping a list of root certificates -- I ignored this for now -- all certificates are untrusted by default).If certificate is declined by the user, connection fails. If it's accepted, it continues.If user chooses to always accept a certificate, Fossil saves it to ~/.fossil database in global_config table with the following format:key=cert:hostnamevalue=PEM certificatewhere PEM certificate is a certificate saved in PEM (text) format:-BEGIN CERTIFICATE-...-END CERTIFICATE-The next time user connects to this hostname, Fossil looks up the certificate in global_config for the hostname and adds its to the trusted certificates list, so that user won't get prompted to accept it again.That's it. It works for me on Mac OS X. Though I haven't yet checked if it actually encrypts anything, but it should :-) (Need a working traffic sniffer...).Feel free to try to compile and test it: http://codingrobots.org/p/fossilPS Also, everything is under #isdef FOSSIL_ENABLE_SSL (which is currently defined in config.h). I'm not good in Makefiles and stuff, so I'm not sure how the actual configuration should be done.--Dmitry ChestnykhCoding Robotshttp://www.codingrobots.comdmi...@codingrobots.com___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] tree checksum does not match
Thanks. BTW, I saw many good changes in fossil last night. I'm pleased :) -Original Message- From: D. Richard Hipp d...@hwaci.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Dec 17, 2009 6:55 pm Subject: Re: [fossil-users] tree checksum does not match On Dec 16, 2009, at 11:43 PM, altufa...@mail.com wrote: Hi DRH, is there any reason content of these files can't be stored in _FOSSIL_ database itself?The manifest and manifest.uuid files are not used by Fossil. Fossil makes those files available for the convenience of the application and the application's makefile. For example, the makefile for SQLite extracts information from its manifest and manifest.uuid in order to generate the sqlite3_sourceid() interface.http://www.sqlite.org/c3ref/libversion.htmlThe makefile for fossil itself also uses these files to construct the version information that is displayed when you type fossil version.If this information were in the _FOSSIL_ file or was only available using the fossil command, then you would not be able to build either SQLite or Fossil from the raw ZIP Archive download or without having a fossil executable on hand. Hence, it is important that the manifest and manifest.uuid files exist.D. Richard hipp...@hwaci.com___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] tree checksum does not match
Well, revert could still be used for reverting selected files but update should also revert any missing files - that's how SCMs have worked. -Original Message- From: Jeremy Cowgar jer...@cowgar.com To: fossil-users@lists.fossil-scm.org Sent: Wed, Dec 16, 2009 9:07 am Subject: Re: [fossil-users] tree checksum does not match Will Duquette w...@wjduquette.com wrote: On Dec 15, 2009, at 5:58 PM, D. Richard Hipp wrote: (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSesdo?) Richard, What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) I wonder if revert wouldn't be better. What I am thinking is that I may not want to update my source tree right now. Maybe I am in the middle of some big changes, autosync is on, etc...Just as if I were to edit abc.txt and blank the content, I could do a fossil revert to get the content back. If I accidentally removed a file, revert it. That will allow me to get it back without fancy trickery (autosync off, or update to my given version).Jeremy___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] 3 Feature requests - globbing using the repository.
My 2 cents. --keep and --force options are intuitive, I would prefer them. - Altu -Original Message- From: Joshua Paine jos...@letterblock.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Dec 10, 2009 3:15 am Subject: Re: [fossil-users] 3 Feature requests - globbing using the repository. On Wed, 2009-12-09 at 22:22 +0100, Stephan Beal wrote: That said, presumably when you rm a file, it already exists in the repo, and the chance of a significant loss due to an unwanted unlink() on the file seems to be small.But the function that the current method provides is one that's reallyneeded sometimes. I.e., don't keep track of this file anymore. I likethat that's convenient, too.So, for what little it's worth, I'd like fossil mv and fossil rm toreally perform the file system operations by default, and let me accessthe current behavior with the --keep flag.If that's not acceptable, let them keep their current default function,but add a --do or --force flag to make them work on the filesystem, too.I agree with Jeremy's proposal to prompt before destroying work thathasn't been committed (and the consequent necessity of the --forceoption).-- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Numbered list syntax?
Me like it too. - Altu -Original Message- From: Wilson, Ronald rwils...@harris.com To: fossil-users@lists.fossil-scm.org Sent: Wed, Dec 9, 2009 6:54 am Subject: Re: [fossil-users] Numbered list syntax? I like it.Ron Wilson, Engineering Project Lead(o) 434.455.6453, (m) 434.851.1612, www.harris.comHARRIS CORPORATION | RF Communications Division assuredcommunications(tm) -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users- boun...@lists.fossil-scm.org] On Behalf Of Jeremy Cowgar Sent: Tuesday, December 08, 2009 6:58 PM To: Fossil User Mailing List Subject: Re: [fossil-users] Numbered list syntax? Any feedback on the below? Jeremy Subject: Numbered list syntax? Hello, I am looking at the source and see that enumerated lists are defined by:1. Hello 2. Goodbye i.e. a two spaces, a number, a period, two spaces, text. Why was it decided to use that syntax instead of the common # syntax? This means that if I have a list of ten things and want to add in an item after position 4, I have to reorder the entire list. In the fossil docs for the rationale of the wiki markup, I read: The wiki markup used by fossil, though limited, is common to most other wiki engines, is intuitive, and is sufficient for 90% of all formatting tasks. I've used a lot of wiki's and have not seen the numbered list syntax of above and it does not seem intuitive either. I made the change to fossil to support# Hello # Goodbye can I commit the change drh? The1. Hello 2. Goodbye syntax is intact and unchanged. Jeremy ___ 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 listfossil-us...@lists.fossil-scm.orghttp://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] external links
Hi DRH, Check-in [0039b7813e] shows a rectangle next to external links in IE and chrome. Is that intentional? I expected to see some other shape. - Altu ___ 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] History for a particular file
Hi DRH, Shall I commit these changes? - Altu -Original Message- From: Venkat Iyer ven...@comit.com To: fossil-users@lists.fossil-scm.org Sent: Wed, Oct 28, 2009 11:48 am Subject: Re: [fossil-users] History for a particular file I am not sure how to get it in, and if it's even worthy of getting in. I made some mods. 1. add help 2. add -l option (for brief and verbose histories) 3. report error for unknown files. I'm not sure if I should pollute this list with code examples. So I moved it to: http://tinyurl.com/ylpr8zw which is really: http://venksi.blogspot.com/2009/10/i-evaled-bunch-of-distributed-version.html I'm working on trying to integrate fossil into emacs vc. - Venkat -Original Message- From: Joshua Paine jos...@letterblock.com Sent: Wednesday, October 21, 2009 10:49:19 Subject: Re: [fossil-users] History for a particular file I would like to see this feature in fossil. How does an enhancement like this make its way into the main codebase? ___ 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] Developing on Unix and Windows
Last time I used vi, it showed ^M at end of each line... does the new version classify files as DOS/Unix and handles edits correctly? - Altu -Original Message- From: Stephen De Gabrielle spdegabrie...@gmail.com To: fossil-users@lists.fossil-scm.org Sent: Fri, Oct 23, 2009 1:44 pm Subject: Re: [fossil-users] Developing on Unix and Windows vi emacs s. On Fri, Oct 23, 2009 at 8:09 AM, altufa...@mail.com wrote: I'm not much familiar with editors in unix. Are there good editors in unix that handle \r\n correctly? - Altu -Original Message- From: Joshua Paine jos...@letterblock.com To: fossil-users@lists.fossil-scm.org Sent: __aolWsbDateToL10n__Wed, 21 Oct 2009 11:42:47 -0400__aolWsbDateToL10n__ Subject: Re: [fossil-users] Developing on Unix and Windows On Wed, 2009-10-21 at 17:09 +0200, Ramon Ribó wrote: 1- A TCL file is checked in on windows 2- It is checked out on unix and line ending is \r\n When the file is created on Windows, it should be created using unix line endings. This is very easy to do in most editors. You can just set it as your default and no one gets hurt. Everything except Notepad can view it fine. 1- I create a nice README or License file for my application in unix 3- README files are open by the user (not by my that I use a wonderful convert-all editor). In Windows, they typically open with Notepad. 4- The file is viewed as with one very long line Since your end users are not likely to checkout your code from fossil, I don't think fossil's behavior is very relevant here. Either create your README with windows line endings, or add some kind of conversion into your build process when you produce packages for end users. For source code, my experience is that unix endings work everywhere for running or viewing--except windows notepad. If there is any language available on both windows and linux where a file will run/compile on windows if it has windows endings *but not* if it has unix endings and likewise will run on linux only with unix endings, then I have some sympathy for your plight. Frankly, though, probably not enough that I would want to see such an ugly feature built into fossil. -- Joshua Paine LetterBlock: Web applications built with joy http://letterblock.com/ 301-576-1920 ___ 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 -- -- Stephen De Gabrielle stephen.degabrie...@acm.org Telephone +44 (0)20 85670911 Mobile+44 (0)79 85189045 http://www.degabrielle.name/stephen ___ 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] Developing on Unix and Windows
My proposal is to use an editor that is aware of DOS and UNIX line endings. - Altu -Original Message- From: Ramon Ribó ram...@compassis.com To: fossil-users@lists.fossil-scm.org Sent: __aolWsbDateToL10n__Wed, 21 Oct 2009 16:36:47 +0200__aolWsbDateToL10n__ Subject: Re: [fossil-users] Developing on Unix and Windows Hello, The conversion of line endings does not affect at all to its sha1 checksum as it is only an input/output filter. The internal representation of the file inside fossil continues to be unique. Some files need conversion and some other no. In cvs, when adding a file it is necessary to specify for every file if it is ascii or not. This property is stored with the file. An alternative could be that the user defined some extensions that need filtering. For example: fossil settings ascii-extensions .tcl .c .cc The problem is that, if fossil does not provide some facility for this, it is very difficult or impossible to implement the solution externally to fossil as an script or something. In any case, what is your proposal for using fossil to manage a program both in unix and windows? 2009/10/21 D. Richard Hipp d...@hwaci.com: On Oct 21, 2009, at 7:57 AM, Ramon Ribó wrote: Hello, When developing the same program on Unix and on Windows, cvs automatically converts the line end of the files to the appropriates for every platform. In this way, if we commit a file in windows that contains \r\n as line ends, we can checkout this file on unix and it will have \n line ends. As I see, fossil does not change the line endings of the ascii files. If we try to work as is, I see several problems, for example, scripts begin with #! on unix do not work if they have \r\n as line end What is the opinion of the fossil users developers on this? What is the suggested method for developing the same program in both unix and windows? will fossil be modified in the future to contain an automatic translation of line endings? Fossil was designed with file integrity in mind. The identifier for a file is its SHA1 checksum. If you start changing line-endings, that changes the SHA1 checksum, and the identity of the file. Furthermore, some file formats are broken by changing line endings. Certainly most binary file formats (GIFs, JPEGs) cannot tolerate line- ending changes. But even some text formats (for example the fossil manifest file) require a specific line ending. D. Richard Hipp d...@hwaci.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
