Re: [fossil-dev] finfo.c cleanup (unused variables)
2017-11-30 12:03 GMT+01:00 Johan Kuuse :
> Hi,
>
> Patch removing unused variables in finfo.c.
Thanks!
<http://www.fossil-scm.org/index.html/info/c699e9fedf918eb8>
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Time for a 2.4 release?
2017-10-30 1:44 GMT+01:00 Richard Hipp: > Version 2.3 has been out for a while. The change log for 2.4 looks > like it is about the right length. I propose to do an official > release soon. Objections? +1. Everything is fine, I don't have any outstanding issues. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] tip of branch-2.3 linking issue
2017-08-24 17:09 GMT+02:00 Martin Gagnon:
> I tried to compile the top of branch-2.3 and found that I get the
> following linking error:
Thanks for reminding me. Was too quick Should be fixed now.
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Release date for version 2.3
2017-07-01 21:50 GMT+02:00 Richard Hipp: > However, I know it > does seem to upset some people when Fossil ships with a non-release > version of SQLite. I wouldn't be upset, it just wouldn't spread out fossil 2.3 as much as desired. I'm afraid various maintainers will skip fossil 2.3, and just wait for 2.4. Or they simply hack fossil, eliminating the need for the SQLITE_PREPARE_PERSISTENT flag. > I suggest we go "pencils down" 2017-07-14. Only bug fixes are > allowed on trunk after that point, until the release. This can be solved by using a "release branch", but I'm sure I don't need to explain that ;-) My suggestion: <http://www.fossil-scm.org/index.html/info/1eab060a84f24fa5> So: - just continue developing on trunk, as usual. - around 2017-07-14, merge everything from trunk to branch-2.3. - development can just continue on trunk, no need for 'pencils down' - bug-fixes appearing on trunk can be cherry-picked to branch-2.3, as far as desired. - on 2017-07-21, release fossil 2.3 from the release branch. Advantage: Fossil-2.3 will ship with SQLite 2.19.3, while trunk development can continue normally. The self-hosting fossil service can continue to use SQLite 2.20 beta. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Git Tag comments, again [Was: Proposed roadmap for Fossil 2.0]
2017-03-31 17:04 GMT+02:00 Richard Hipp: > I don't understand the details of this issue, but my instinct would be > to use the T card to avoid an incompatibility. Thanks! Does that mean that the "jn-export" branch can be merged to trunk? Then GIT tag comments will sync with fossil, both ways. Regards, Jan Nijtmans > > On 3/31/17, Jan Nijtmans wrote: >> 2017-03-30 21:24 GMT+02:00 Richard Hipp: >>> On 3/30/17, Jan Nijtmans wrote: >>>> Ping .Could this be decided for Fossil 2.2? Please? >>> >>> libfossil is a non-trivial undertaking. Because of the way Fossil is >>> currently architected, libfossil is basically a ground-up rewrite. >> >> Hm. My question had no relation to libfossil, it was related to this >> requested feature: >> >> <https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24595.html> >> >> Allowing Git tag comments is already implemented by Roy Marples, and I >> modified it a little bit. The question is: Should a 'C' card be used for the >> tag comments (which causes a format incompatibility), or should we use >> the - already existing - 'T' card. >> >> It's just a matter of deciding which would be best, Roy and I differ in >> opinion. So, Richard, if you indicate which version "roy-export" or >> "jn-export" you prefer, then that's one less hurdle for GIT people >> to switch to fossil ;-) Would be nice for fossil 2.2 anyway. >> >> Details can be found in the above link to the fossil-users mailing list. >> >> Thanks, >> Jan Nijtmans >> ___ >> fossil-dev mailing list >> fossil-dev@mailinglists.sqlite.org >> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev >> > > > -- > D. Richard Hipp > d...@sqlite.org > ___ > fossil-dev mailing list > fossil-dev@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
[fossil-dev] Git Tag comments, again [Was: Proposed roadmap for Fossil 2.0]
2017-03-30 21:24 GMT+02:00 Richard Hipp: > On 3/30/17, Jan Nijtmans wrote: >> Ping .Could this be decided for Fossil 2.2? Please? > > libfossil is a non-trivial undertaking. Because of the way Fossil is > currently architected, libfossil is basically a ground-up rewrite. Hm. My question had no relation to libfossil, it was related to this requested feature: <https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg24595.html> Allowing Git tag comments is already implemented by Roy Marples, and I modified it a little bit. The question is: Should a 'C' card be used for the tag comments (which causes a format incompatibility), or should we use the - already existing - 'T' card. It's just a matter of deciding which would be best, Roy and I differ in opinion. So, Richard, if you indicate which version "roy-export" or "jn-export" you prefer, then that's one less hurdle for GIT people to switch to fossil ;-) Would be nice for fossil 2.2 anyway. Details can be found in the above link to the fossil-users mailing list. Thanks, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
[fossil-dev] Fwd: [fossil-users] Proposed roadmap for Fossil 2.0
Ping .Could this be decided for Fossil 2.2? Please? Thanks, Jan Nijtmans -- Forwarded message -- From: Roy Marples Date: 2017-02-26 23:03 GMT+01:00 Subject: Re: [fossil-dev] [fossil-users] Proposed roadmap for Fossil 2.0 To: fossil-...@lists.fossil-scm.org On 26/02/17, Richard Hipp wrote: > My goal is to keep changes to a minimum. The only change is to add > support for multiple hash algorithms. If neither the roy-export or jan-export branches are planned to be merged to trunk for 2.0, can we get consensus on how the tag comment should actually be stored in Fossil? A comment card against the tag, or the tag value field. I'd like to be able to tell my users on the other side of the fossil <-> git bridge they can stop adding tags without comments. Roy ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] andygoth-branch-list
Op 19 nov. 2016 6:25 p.m. schreef "Richard Hipp": > On 11/19/16, Andy Goth wrote: > > Going forward, which definition do we want? > > I think the definition used by /brlist. > > Reasoning: > (1) I don't think the difference is all that important. If you have > multiple branches with the same name, then you probably deserve > whatever it is that happens. > (2) The /brlist definition is easier to compute I concur. A closed branch should be a branch in which all leaves are closed. That's what I would expect. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Fwd: The results of your email commands
Op 18 okt. 2016 8:00 a.m. schreef "Stephan Beal": > Fyi, the "too many bounces" problem is now apparently hitting gmail users. AFAIK gmail never bounces. Yeah, I got it too ... Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Time to release version 1.35?
2016-06-13 17:21 GMT+02:00 Stephan Beal: > That reminds me: i found a workaround for the "strict type punning" > warning[1] in cson reported a few weeks ago, but it will likely be the > weekend before i can patch and test it. It's not important for a release, in > any case, just a "nice to have" with certain gcc versions. > > > [1] = use memcpy() instead of *ptrDeref=foo. Something like this? <http://fossil-scm.org/index.html/vinfo/6ef54dfaf7fd90a4?sbs=1&w> Thanks! Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Time to release version 1.35?
> On Mon, Jun 13, 2016 at 1:26 PM, Richard Hipp wrote: >> So the question becomes: Is your enhancement important enough to >> delay the release by two months? Or is it better to get 1.35 out >> Tuesday morning and deal with your enhancement for 1.36?2016-06-13 21:33 >> GMT+02:00 Scott Robison: On 6/13/16, Scott Robison wrote: > Nope, not important enough at all. The current implementation identifies all > byte sequences identically to mine. I think 1.35 is ready to be released. Actually I like Scott's enhancement too, a table-based approach can indeed be made faster than custom byte-level checks, so this is definitely the way to go. The way it is now (runtime-initialization of a constant table) could be improved upon further, I'll be happy to have a look at this after 1.35 is out. Thanks! Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Time to release version 1.35?
2016-06-10 16:01 GMT+02:00 Richard Hipp: > Any objections to cutting the Fossil 1.35 release sometime early next week? Not at all! A look at at least the "reparent" and "andygoth-import" branches would be appreciated. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] [fossil-users] Time to release Fossil version 1.34?
2015-10-21 14:13 GMT+02:00 Martin Gagnon: > On Wed, Oct 21, 2015 at 3:26 AM, Jan Nijtmans wrote: >> 2015-10-20 19:51 GMT+02:00 Joe Mistachkin : >>> I've moved the backout off trunk so the issues that remain, if any, can >>> be fixed prior to the release. > In the mean time, I fix the CLI "timeline -v" command which is the fix > that should have been done in the first place on the > timeline_showfiles_fix branch to solve the discrepancy between > the CLI and webpage for the list of modified files on a check-in. Looks OK to me, I indeed think the issue is resolved now. Thanks for all your work! Trunk is already deployed on core.tcl.tk (thanks Richard!), which means the Fossil release is good to go IMHO. I don't have any pending issues any more. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] [fossil-users] Time to release Fossil version 1.34?
2015-10-20 19:51 GMT+02:00 Joe Mistachkin : > Jan Nijtmans wrote: >> >> It turns out that the cause of this problem is the following commit: >> <http://www.fossil-scm.org/index.html/info/9431fec1ea098fea> >> so I backed it out. My local trunk build doesn't show the problem >> any more. >> > > Actually, it appears you backed out two check-ins. The original one and > the follow-up that fixed the timeline issue it had. Yes, that was on purpose. Since the second commit fixed a problem in the first one, only backing out the first would would result in left-over dead code. > I've moved the backout off trunk so the issues that remain, if any, can > be fixed prior to the release. It's up to you (or Richard) to review it. Please don't take too long, it's only a few lines of code. And people are already complaining about this issue. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Check-in etiquette
2015-08-27 11:03 GMT+02:00 Baruch Burstein :
> I made the change locally in my makefile and used it. I then made the same
> change in the tcl script and committed that one.
> I guess I could have just committed my hand-changed makefile.
Slightly better would have been to commit it to the "pending-review"
branch. Then someone who has Tcl installed can review the change,
re-generate the makefiles, test it and merge everything
to trunk. This way you eliminate any potential risk, while
still providing your improvements to whoever is interested.
In this case, the change was trivial to be understood, no
harm whatsoever was done.
Regards,
Jan Nijtmans
___
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Check-in etiquette
2015-08-27 9:33 GMT+02:00 Baruch Burstein : > Hi, > > I know that when making changes to makemake.tcl, I am expected to run the > script to generate the new makefiles and check them in as well. However, I > am on a computer where I cannot easily install TCL (company policy). I > committed the changes to makemake.tcl without regenerating the makefiles, > leaving that to someone else. Is this acceptable? Joe already correct that: <http://www.fossil-scm.org/index.html/info/e947fce957171e44> Thanks! The only potential problem: people might wonder how you tested the change. In this case, your change works fine and looks good to me. Joe apparently agreed with this change, I agree as well. Well done! Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] [Q] Update .ignore-glob to include build artifacts on Linux
Op 16 aug. 2015 19:45 schreef "Chris Drexler" het volgende: > I overlooked that those files would not get cleaned up either then :-(. It is possible to set ignore-glob as you suggest and still do a full clean: just use "fossil clean -x". That's what I use in my repositories. "fossil clean" only removes temporary files, log files and other files like that, not files specified with ignore-glob. "fossil clean" and, "fossil clean -x" are functionally similar to the corresponding GIT commands, if you set ignore-glob as you would set GIT's ".gitignore". It's a choice whether you want to use ignore-glob like that or not. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Build system changes on Windows
2015-06-17 2:29 GMT+02:00 Jan Danielsson : >Feature: On a few systems I want to have a dynamically linked > fossil.exe. I'm thinking "FOSSIL_DYNAMIC_LINK=1" (changes default ZLIB > to zdll.lib, /MT -> /MD, and link against DLL CRT). Well, I would expect this to be two different options: /MT vs /MD controls the C runtime being dynamic or not (which I would expect FOSSIL_DYNAMIC_LINK to do), but whether ZLIB is linked in dynamically should be a separate choice. On windows, I don't see any reason to use a dynamic zlib, it only complicates the re-distribution of fossil.exe since zlib1.dll then always needs to be re-distributed with it. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Confirm removal of an empty directory?
2015-04-29 11:43 GMT+02:00 Jan Nijtmans : > 2015-04-29 3:37 GMT+02:00 Andy Bradford : >> Thus said Richard Hipp on Tue, 28 Apr 2015 13:00:13 -0400: >>> Why does "fossil clean --emptydirs" prompt for confirmation before >>> removing an *empty* directory? > I'm willing to implement that (unless some-one is faster > than me ;-) Done: <http://www.fossil-scm.org/index.html/info/0db0fdb27eff8c4d> Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] Confirm removal of an empty directory?
2015-04-29 3:37 GMT+02:00 Andy Bradford : > Thus said Richard Hipp on Tue, 28 Apr 2015 13:00:13 -0400: >> Why does "fossil clean --emptydirs" prompt for confirmation before >> removing an *empty* directory? ... > Seems if --emptydirs is set and there is not an empty-dir setting that > exempts it, it should be removed. +1 Initially I was inclined to simply respond 'Yes' to Richard's question, but I totally forgot about the empty-dir setting. So, in stead of asking for confirmation, fossil should look in "empty-dirs". If the directory name matches "empty-dirs", it should be kept, otherwise it should be removed without asking for comfirmation. I'm willing to implement that (unless some-one is faster than me ;-) Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] dotfiles setting is now versionable
2015-04-01 21:42 GMT+02:00 Scott Robison : > I modified the dotfiles setting to make it versionable. I also did it > "recklessly" by putting it directly on trunk. Just mentioning it in case > anyone had a problem with it. So no need to merge anything to trunk this > time, but you can move it off trunk if needed. :) In general, I'm very carefull making settings versionable, e.g. I have my doubts whether 'tcl-setup', 'th1-setup', and 'th1-uri-regexp' [http://www.fossil-scm.org/index.html/info/1c528d3bb9e07428d1a3] should have been versionable at all: those settings will typically be set on the repository which functions as 'server', not the clones. But I'll leave that to Richard to decide, if he wants to change that. In your case, however, setting 'dotfiles' is typically done on a repository which has many dotfiles committed, so it makes perfectly sense to make this setting versionable such that all clones inherit it as well. That's exactly what versionalble settings are meant for. Thanks for the suggestion! Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The --docker option
2015-03-19 9:07 GMT+01:00 Jan Nijtmans : > 2015-03-18 18:41 GMT+01:00 Richard Hipp : >> Perhaps the right way to handle this case is to modify >> https://www.fossil-scm.org/fossil/info/2e4de226a7?ln=1066-1110 so that >> if >> >> (1) The operation is "push", and >> (2) There is exactly one entry in the BLOB table, and >> (3) That one BLOB entry is a manifest >> >> Then it will overwrite the PROJECTCODE and "DELETE FROM blob; DELETE >> FROM plink; DELETE FROM event;" before proceeding. (The SERVERCODE is >> an historical artifact that is no longer used for anything and can be >> safely ignored.) This would permit any repository to push into a >> freshly created repo and the freshly created repo would take on the >> identity of the repository that is doing the push. > > I like this idea. Thanks! Even though I like this approach there is a problem: In the "user" table, the password is not saved as-is, but it takes the form of a hash which is constructed taking the "project-code" into account. So, as soon as the project-id of an existing project is changed, all current passwords stop working: no-one can log-in any more! See: <http://fossil-scm.org/index.html/artifact/475f5dc5fd546d3e?ln=367-382> If the project-code is not set, the password is stored unhashed, so that's the way out as I currently see it. Hacking continues .. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The --docker option
2015-03-18 18:41 GMT+01:00 Richard Hipp : > Perhaps the right way to handle this case is to modify > https://www.fossil-scm.org/fossil/info/2e4de226a7?ln=1066-1110 so that > if > > (1) The operation is "push", and > (2) There is exactly one entry in the BLOB table, and > (3) That one BLOB entry is a manifest > > Then it will overwrite the PROJECTCODE and "DELETE FROM blob; DELETE > FROM plink; DELETE FROM event;" before proceeding. (The SERVERCODE is > an historical artifact that is no longer used for anything and can be > safely ignored.) This would permit any repository to push into a > freshly created repo and the freshly created repo would take on the > identity of the repository that is doing the push. I like this idea. Thanks! Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The --docker option
2015-03-18 15:20 GMT+01:00 Richard Hipp : > Trunk now supports the --create option to "fossil server" which > creates the repository if it does not exist. This seems like a safer > approach that trying to half-create a repository when the docker is > instantiation and then finishing the creation process when the docker > is first run. Yes, I can see the advantage of that, but it's not a complete solution yet. When running fossil within Docker, there are two ways to fill the repository with artifacts: 1) If the container is intended to server a new repository, a client will simply clone the repository and start committing. All is well in this case. 2) If the container is intended to host an already existing repository, the project-id needs to be modified (using sql) and an external fossil somewhere will do a sync. This approach will result in the Chiselapp "I have two trunks" problem. Indeed, the --create option can be used as alternative to --docker, solving case 1). For 2) this is not a solution yet. Thanks! I will try this approach when fossil 1.33 is out, for now at least there is a working 1.32 fossil image with a solution for both 1) and 2). Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] The --docker option
2015-03-17 22:18 GMT+01:00 Richard Hipp : > What is the proposed purpose of the --docker option to "fossil init"? > Presumably it has something to do with the Docker container system. > But I do not understand what that is, exactly? Why does Fossil need > special options in order to work with Docker? The easiest way to try this, is to type the following on any system which has Docker installed: sudo docker run -d -p 8080:8080 nijtmans/fossil See: https://registry.hub.docker.com/u/nijtmans/fossil/ "fossil init --docker" produces a repository without project-id and server-id. This repository is not usable as-is. But as soon as "docker server" is started, that's when the project-id and server-id is generated. Without the --docker option all fossil docker containers in the whole world would have the same project-id and server-id. Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] svn-import branch
2015-02-24 10:09 GMT+01:00 Jan Nijtmans : > Both branches are IMHO ready to be merged to trunk, that's > the best way to get them tested by more people. Any objections, merging the "svn-import" branch to trunk? Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] svn-import branch
2015-02-25 19:53 GMT+01:00 Baruch Burstein : > I don't think there needs to be an extra switch (--no-svn-rev) for this. I > think the existing --incremental switch should be used. The default will be > to not have the svn-rev-* tags. That sounds logical, so it's committed now to the "svn-import" branch. Any more remarks by anyone? Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
Re: [fossil-dev] svn-import branch
2015-02-23 23:57 GMT+01:00 Martin Gagnon : > What do you think ? > > - Can this branch be merge to svn-import ? Both branches are IMHO ready to be merged to trunk, that's the best way to get them tested by more people. The one thing to decide (by Richard) is whether there are options --git/--svn (as in trunk) or a separate "format" parameter. Personally, I would prefer to keep the options as they are now, for two reasons: - compatibility with currently existing scripts - possible future extensibility, in which the import type is detected from the input file automatically. > > - Do you have preference for the option name ? > It is actually named: --no-svn-rev It's OK to me. > > - Should the automatic tagging be off by default ? I don't have a strong opinion on this, but since the additional tags don't take that much space (compared with other things that need to be stored for each commit) I would prefer automatic tagging to be on be default. My 2c. Thanks for all the great work, Martin and Baruch! Regards, Jan Nijtmans ___ fossil-dev mailing list fossil-dev@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
