[fossil-users] Possible rename/revert bug?
Hello all! I ran into some odd behavior with running revert on a checkout in which a rename has just been performed. The renamed file gets deleted, but the original file doesn't get restored. No changes are reported by 'fossil changes', although the checkout is certainly not in its original state. The fastest way to do that is to just close and reopen the repo. Alternatively, you could run undo, rename the file back, and then run revert again. That would get more annoying if you had renamed multiple files, obviously. I also noticed that you can recover the original file by calling revert on the original filename, but then fossil appears to see it as a new file (it appears as ADDED in the output of 'fossil addremove --test'). This should be easy to reproduce. Just create a repo and commit a file into it. Then change that file's name and run 'fossil mv'. Finally, run 'fossil revert' and you should see the behavior I've described. Is this the proper behavior for revert? Is there a different way I should handle this scenario? Is this a legitimate bug that I should file a ticket for (I couldn't find an existing one)? Am I a moron? The answer to one of these questions is certain to be yes! Thanks for the help! ___ 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] Possible rename/revert bug?
On Mon, Jan 7, 2013 at 10:00 AM, Joel Bruick joelbru...@msn.com wrote: This should be easy to reproduce. Just create a repo and commit a file into it. Then change that file's name and run 'fossil mv'. Finally, run 'fossil revert' and you should see the behavior I've described. FWIW, here's a reproduction: [stephan@host:~/cvs/fossil]$ mkdir foo [stephan@host:~/cvs/fossil]$ cd foo [stephan@host:~/cvs/fossil/foo]$ f new ../foo.fsl project-id: 64987e5fdcdaca95f9d3a0e84e0167c5383651bb server-id: 0a5c186da86a4ed0f787b2e616a8e61a4ab2eef8 admin-user: stephan (initial password is 79d1e3) [stephan@host:~/cvs/fossil/foo]$ f open ../foo.fsl [stephan@host:~/cvs/fossil/foo]$ touch foo.bar [stephan@host:~/cvs/fossil/foo]$ f add foo.bar ADDED foo.bar [stephan@host:~/cvs/fossil/foo]$ f com -m egg foo.bar New_Version: c8ec925d1981bcbabf6fdcc856bda53fd1c13ee5 [stephan@host:~/cvs/fossil/foo]$ mv foo.bar bar.foo [stephan@host:~/cvs/fossil/foo]$ f mv foo.bar bar.foo RENAME foo.bar bar.foo [stephan@host:~/cvs/fossil/foo]$ f revert DELETE: bar.foo fossil undo is available to undo changes to the working checkout. [stephan@host:~/cvs/fossil/foo]$ l total 24 drwxrwxr-x 2 stephan stephan 4096 Jan 7 10:13 . drwxrwxrwx 46 stephan stephan 4096 Jan 7 10:13 .. -rw-r--r-- 1 stephan stephan 13312 Jan 7 10:13 .fslckout That said, i'm not at all familiar with those particular bits and my day job has priority on my time for the foreseeable future, so i will have to defer the investigation/fix to someone who knows those parts :/. Is this the proper behavior for revert? My assumption is no. Is this a legitimate bug that I should file a ticket for (I couldn't find an existing one)? Yes, please. Am I a moron? Based solely on this post, i'd have to say no ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [revert] Shortcut to go back to n-1 revision?
Hello I often want to try something new, commit the change even if it didn't work (just to keep track of things I tried), and go back to the n-1 revision from the repository. I checked the page for revert, but it doesn't mention it: Is there a shortcut like... fossil revert beforelast www.fossil-scm.org/index.html/help?cmd=revert ... as an alternative to running fossil finfo myfile, finding the artifact ID of the revision, and running fossil revert artifactID to go back to the last good revision? Also, and more generally, am I correct in understanding that running fossil commit commits all the files that have been edited, and it's not possible to commit just one file? The reason I ask is that I created a repository at the top of where I keep all the little projects I'm working on, eg. c:\projects\projects.repo. I know I should create a repository per project, but I'd end up with ten's of them, each with just a few files. Thank you. ___ 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] [revert] Shortcut to go back to n-1 revision?
On Mon, Jan 7, 2013 at 11:10 AM, Gilles gilles.gana...@free.fr wrote: fossil revert beforelast www.fossil-scm.org/index.html/help?cmd=revert So far there is no shortcut for that. If you don't mind, please open up a feature request for that. IIRC that request has come up a few times before. Also, and more generally, am I correct in understanding that running fossil commit commits all the files that have been edited, and it's not possible to commit just one file? Sure you can: fossil commit file1 ... fileN The first line of the help text is a bit misleading: Create a new version containing all of the changes in the current checkout. but goes on to say: All files that have changed will be committed unless some subset of files is specified on the command line. The reason I ask is that I created a repository at the top of where I keep all the little projects I'm working on, eg. c:\projects\projects.repo. I know I should create a repository per project, but I'd end up with ten's of them, each with just a few files. [stephan@host:~/cvs/fossil]$ ls -1 *.fsl | wc -l 38 ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [revert] Shortcut to go back to n-1 revision?
On Mon, 7 Jan 2013 11:20:20 +0100, Stephan Beal sgb...@googlemail.com wrote: So far there is no shortcut for that. If you don't mind, please open up a feature request for that. IIRC that request has come up a few times before. Thanks for the info. [stephan@host:~/cvs/fossil]$ ls -1 *.fsl | wc -l 38 I guess I'll move to one project = one repo. ___ 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] [revert] Shortcut to go back to n-1 revision?
On Mon, Jan 7, 2013 at 11:33 AM, Gilles gilles.gana...@free.fr wrote: [stephan@host:~/cvs/fossil]$ ls -1 *.fsl | wc -l 38 I guess I'll move to one project = one repo. There's no strict reason to - if your current model works for you then by all means use it. i keep mine separated, but that's just personal preference. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] [VB.Net] Ignoring .suo safe?
Hello I just ran the following two commands: fossil add ./MyVBNetProject fossil commit -m Original files ... and fossil complains with: ./MyVBNetProject/WindowsApplication1/WindowsApplication1.suo contains binary data. commit anyhow (a=all/y/N)? My global ignore-glob contains: *.exe,*.pdb,*.vb~*,*/bin/*,*/obj/* I assume there are VB.Net developers using Fossil: Do you know if it's safe to ignore the .suo file? Generally speaking, is my ignore-glob OK for VB.Net? Thank you. ___ 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] [revert] Shortcut to go back to n-1 revision?
On Mon, 7 Jan 2013 11:43:01 +0100, Stephan Beal sgb...@googlemail.com wrote: There's no strict reason to - if your current model works for you then by all means use it. i keep mine separated, but that's just personal preference. Thanks. ___ 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] [VB.Net] Ignoring .suo safe?
On Mon, Jan 07, 2013 at 11:49:52AM +0100, Gilles wrote: I just ran the following two commands: fossil add ./MyVBNetProject fossil commit -m Original files ... and fossil complains with: ./MyVBNetProject/WindowsApplication1/WindowsApplication1.suo contains binary data. commit anyhow (a=all/y/N)? My global ignore-glob contains: *.exe,*.pdb,*.vb~*,*/bin/*,*/obj/* I assume there are VB.Net developers using Fossil: Do you know if it's safe to ignore the .suo file? Generally speaking, is my ignore-glob OK for VB.Net? Yes, it's safe. Basically, the only set of files really needed for maintaining a .NET project by the Microsoft IDE are those containing XML in them. The `msbuild` tool which does actual heavy lifting consumes files ending in '*.proj' (or '*.csproj' or '*.vbproj' or whatever), plus there is a top-level XML file which represents the solution and its settings, and references those project files consumed by msbuild. ___ 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. Git/Mercurial/etc.?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 05:12 PM, Richard Hipp wrote: Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. Yep; that hides all the private branch history into the private repo, though - what I'm talking about *looks* like that but has the history available to everyone if you expand the commit by clicking on a [+] in the web UI or some such. ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDqsj8ACgkQRgz/WHNxCGo76ACdF0rjW4NqXpNFSR8Z4gdItTHF m/MAn2nj/pIFIXaAuSYbL5m+DHO2LpSs =bGDp -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [VB.Net] Ignoring .suo safe?
On Mon, 7 Jan 2013 15:12:19 +0400, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: Yes, it's safe. Basically, the only set of files really needed for maintaining a .NET project by the Microsoft IDE are those containing XML in them. The `msbuild` tool which does actual heavy lifting consumes files ending in '*.proj' (or '*.csproj' or '*.vbproj' or whatever), plus there is a top-level XML file which represents the solution and its settings, and references those project files consumed by msbuild. Thanks for the feedback. So I'll commit the following files from VB Express and ignore the rest: *.sln *.resx *.user *.vb *.vbproj *.settings *.myapp ___ 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] [VB.Net] Ignoring .suo safe?
On Mon, Jan 07, 2013 at 12:32:43PM +0100, Gilles wrote: Yes, it's safe. Basically, the only set of files really needed for maintaining a .NET project by the Microsoft IDE are those containing XML in them. The `msbuild` tool which does actual heavy lifting consumes files ending in '*.proj' (or '*.csproj' or '*.vbproj' or whatever), plus there is a top-level XML file which represents the solution and its settings, and references those project files consumed by msbuild. Thanks for the feedback. So I'll commit the following files from VB Express and ignore the rest: *.sln *.resx *.user *.vb *.vbproj *.settings *.myapp Seems to be OK, but note that those .user and .settings file are not really a part of the solution's core (I'm not sure I ever saw a .myapp file so have nothing to say on this). What I mean, is that it might be useful to keep these files in the repository, but if you will eventually decide to ship a tarball of your source code (if it's a F/OSS project), then you will probably want to strip those files out. Note that there were tools to do exactly this. Can't recall any name at the moment, but I'm sure it's googleable. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Diff summary when clicking on timeline box (feature request)
Hi list, I like very much the new feature where we can click on 2 versions directly on the timeline. But there's a little thing missing when diffing that way, there's no way to see a compact list of files that change, all files diff are already expanded. Sometimes, there's a lot of files with differences but I'm interested in only one or two, having a condensed list of changed files with a [diff] link beside it would be very useful Of course, a button to toggle between expanded diff and condensed diff would be necessary because sometimes we want to see all the diff.. Does it make sense ? -- Martin G. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Possible rename/revert bug?
On Mon, Jan 7, 2013 at 4:22 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jan 7, 2013 at 10:00 AM, Joel Bruick joelbru...@msn.com wrote: This should be easy to reproduce. Just create a repo and commit a file into it. Then change that file's name and run 'fossil mv'. Finally, run 'fossil revert' and you should see the behavior I've described. FWIW, here's a reproduction: I think this is fixed in trunk now (see http://www.fossil-scm.org/fossil/info/48798b2719). Please follow-up if you disagree. -- 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] 'fossil server' fails to chroot
Hello,
when I open ('fossil open') a repository located in the root ('/'),
where the current work dir is one below the root (say, '/mydir'),
'fossil server' results in an error message in my browser, when I view
'http://localhost:8080':
Status: 200 OK
X-Frame-Options: SAMEORIGIN
Cache-control: no-cache
Content-Type: text/html; charset=utf-8
Content-Length: 50
p class=generalErrorunable to chroot into /p
(I literally see this text in the browser window).
Environment:
$ fossil version
This is fossil version 1.25 [48798b2719] 2013-01-07 15:03:43 UTC
$ uname -a
NetBSD lime 6.0.1 NetBSD 6.0.1 (GENERIC) amd64
I tried with both static ('./configure --static make') and dynamic
binaries; both fail.
Dynamic binary works ok if I open the repository one dir further from
the root (i.e. '/foo/bar' instead of '/foo'), while repository is
still located in the root. (I didn't try with static binary anymore.)
Not urgent, but ran into this by accident.
With kind regards,
Michai Ramakers
___
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. Git/Mercurial/etc.?
On Mon, Jan 7, 2013 at 4:32 AM, Alaric Snell-Pym ala...@snell-pym.org.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/03/2013 05:12 PM, Richard Hipp wrote: Might that be a useful approach for Fossil, too? If I understand you correctly, I believe this is what happens if you do your lots of tiny commits into a --private branch, then merge that private branch into trunk (or some other public branch) at the end. When you push to another repo, on the other repo that does not contain the private branch, the merge looks like a single commit that contains all of the changes all mashed together into one big change. Yep; that hides all the private branch history into the private repo, though - what I'm talking about *looks* like that but has the history available to everyone if you expand the commit by clicking on a [+] in the web UI or some such. This is exactly what I would like to see. Literally a mechanism to mark branches hidden where the markers are propagated on sync is all it would take. A .fossil-settings/hidden-branches file might be a good way to achieve this. from my previous post I could do my messy work on a branch that I will later hide and when happy with the result merge to a branch that I would keep visible. This keeps history intact but makes a nice uncluttered clean view available that captures only the important aspects of development and hides the noise. = ABS - -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDqsj8ACgkQRgz/WHNxCGo76ACdF0rjW4NqXpNFSR8Z4gdItTHF m/MAn2nj/pIFIXaAuSYbL5m+DHO2LpSs =bGDp -END PGP SIGNATURE- ___ 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. Git/Mercurial/etc.?
Hi! On Sat, Dec 29, 2012 at 11:56 PM, Nico Williams wrote: I happen to think that Fossil has a superior architecture and design. I'd like to use Fossil, but I can't, and I've explained why. I've also explained why I'm unlikely to be the only user who needs this one feature. Thank you Nico for thorough explanations about the benefits of a rebase-like feature and how it could grow our userbase. I hope there will one day be a rebase-like feature in Fossil, in line with the superb Fossil philosophy. Thank you Nico for your interest and energy to make Fossil better and more widely appealing. Best regards, M ;-) -- Marc Laporte http://MarcLaporte.com http://Tiki.org/MarcLaporte http://AvanTech.net http://svg-edit.googlecode.com http://jquerysheet.googlecode.com http://sourceforge.net/p/jcapture-applet/ On Mon, Dec 31, 2012 at 6:02 PM, Nico Williams n...@cryptonector.com wrote: Thanks Mike, I appreciate this. BTW, I now have a pretty good idea of what fossil rebase would look like; the discussion was a success, largely thanks to Joerg's insight. I've also started looking at src/merge.c to have an idea of how to implement a version of fossil merge --cherrypick that doesn't commit the merged changes (this being necessary to implement the interactive rebase edit-a-commit option, as well as for squashing) -- this is the essential ingredient, after all, and it seems like all that has to happen is we need an option to not update any non-temp tables in merge_cmd(). I think that will be a trivial change, actually, as it'd be a small modification to the fossil merge --nochange logic. I'll stop here. In six months I may have time to actually implement, and in the meantime I'll sketch an implementation. Happy New Year! ___ 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
