[fossil-users] How to push single branch to another repository?
Hi List, In one of my projects I am mostly working on one specific branch XYZ. But, being a novice fossil user, I mistakenly messed up the trunk. Now, how can i push only my branch XYZ without pushing whatever was entered into the trunk? Is shunning my only option? Are there plans to implement one-branch push/pull in the future? Thanks, --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] Retro side-by-side diffs
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 ___ 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
On Fri, Feb 03, 2012 at 10:25:41AM -0500, Richard Hipp 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? Hello, I like how it looks. I also liked the colourful, but with tuned colours (I'm a bit used to 'meld' and its colours, for hard diffs). I definitely prefer this retro sbs over the colourful. I don't know if the option can be given simply as CSS styles, though. Emitting some (html tags allowing for colourful sbs is possible? Apart, one feature I'd like a lot is to have sbs diffs with the *option not to skip lines*. That's usally a nice option that sbs diffs can give over unified diffs: full context. Regards, Lluís. ___ 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
On 02/03/12 16:25, Richard Hipp wrote: [---] Are there strong preferences one way or another? There are two aspects I prefer with the original: - I think color coding makes it easier to get a quick overview of what's happened in a diff. (I see a lot of red is roughly optimizations, I see a lot of green is roughly New features). - I haven't looked at the code lately, but does the web sbsdiff support the width argument in some manner? For quite a few diffs I've been looking at lately, static 80 characters wide panes leaves a lot of empty wasted space, due to short lines. Those points aside, I strongly support the idea of unifying the two, so overall I'm for the retro sbsdiff. -- Kind regards, Jan Danielsson ___ 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
My preference would be to keep the color SBS diffs, at least as a skin option or something, since I find it easier to notice changes and match them up. Maybe somewhere in the documentation on the header / skin, there could be css for a default coloring of the sbs diffs that one could copy into the header? Tomek On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: On 02/03/12 16:25, Richard Hipp wrote: [---] Are there strong preferences one way or another? There are two aspects I prefer with the original: - I think color coding makes it easier to get a quick overview of what's happened in a diff. (I see a lot of red is roughly optimizations, I see a lot of green is roughly New features). - I haven't looked at the code lately, but does the web sbsdiff support the width argument in some manner? For quite a few diffs I've been looking at lately, static 80 characters wide panes leaves a lot of empty wasted space, due to short lines. Those points aside, I strongly support the idea of unifying the two, so overall I'm for the retro sbsdiff. -- Kind regards, Jan Danielsson ___ 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] Retro side-by-side diffs
On Fri, Feb 3, 2012 at 8: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? I will miss the colors as I tend to rely on color in tools like tkdiff, meld and xxdiff to give me a big picture view and to draw my eye to the changes. The compressed summary (in the center scroll bar in tkdiff and on the rhs in meld is extremely useful but I doubt that can be easily replicated in fossil so maybe keeping it simple in the browser and leaving the more powerful interface to external tools makes sense. Just my $0.02 -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil rm followed by unix rm followed by update and files come back, is this desirable?
If I do: fossil rm some/file.txt rm some/file.txt ...do stuff... fossil update then some/file.txt is resurrected which is really really annoying when you just got your build to work and then because files that shouldn't be there suddenly reappear and things break. I can see where might be some controversy in the behavior of fossil update in this situation. Is there a good practice that avoids the hassle from the files coming back? I've been telling folks to update often to stay in sync and in this case that can cause annoyance and time wasting. The one possible methodology I can see is to use stash but it seems both overly complicated and actually this behavior seems to violate this phrase in the fossil update help Any uncommitted changes are retained and applied to the new checkout. : fossil rm some/file.txt rm some/file.txt ...do stuff... fossil stash fossil update fossil stash pop ___ 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
On 02/03/12 17:01, Tomek Kott wrote: My preference would be to keep the color SBS diffs, at least as a skin option or something, since I find it easier to notice changes and match them up. Maybe somewhere in the documentation on the header / skin, there could be css for a default coloring of the sbs diffs that one could copy into the header? The layout is so fundamentally different that it's not really possible to do it that easily. In essence, the old sbsdiff used HTML (tables and such), the new one essentially creates a textfile and shows it in a pre-formatted section. That said, it shouldn't be impossible to get color coding with the new/retro version: When I started working on the original sbsdiff, someone was afraid I was going to break their javascript solution for getting colored unified diffs. If javascript can be used to make uncolored unified diffs colored, then I see no reason the same couldn't be done for side-by-side diffs. -- Kind regards, Jan Danielsson ___ 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
On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: - I haven't looked at the code lately, but does the web sbsdiff support the width argument in some manner? For quite a few diffs I've been looking at lately, static 80 characters wide panes leaves a lot of empty wasted space, due to short lines. It does as of a few moments ago. The dw= URI query parameter controls column width (default 80, max 255). The dc= query parameter controls the number of lines of context (default 7, max 4095). Example: http://www.fossil-scm.org/fossil/ci/6474a92a87?sbs=1dw=60dc=20 -- 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] documentation clarification
On Wed, Feb 1, 2012 at 8:03 AM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. I was in a situation where this was happening regularly. I got warnings about the clocks being out of sync from fossil. I'm no longer in that situation (and traveling), so I can't easily test it, but isn't that still the case? mike ___ 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
On Fri, Feb 03, 2012 at 11:19:38AM -0500, Richard Hipp wrote: On Fri, Feb 3, 2012 at 10:47 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: - I haven't looked at the code lately, but does the web sbsdiff support the width argument in some manner? For quite a few diffs I've been looking at lately, static 80 characters wide panes leaves a lot of empty wasted space, due to short lines. It does as of a few moments ago. The dw= URI query parameter controls column width (default 80, max 255). The dc= query parameter controls the number of lines of context (default 7, max 4095). Example: http://www.fossil-scm.org/fossil/ci/6474a92a87?sbs=1dw=60dc=20 Great! dc=-1 seems to work for full context though, in a quick check. :) I can't tell if does more than 4095, in that page. Regards, Lluís. ___ 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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit -- Dmitry Chestnykh http://www.codingrobots.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] Retro side-by-side diffs
On 2/3/2012 7:25 AM, Richard Hipp 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? (At this point I haven't looked at all the other responses which seem to have gotten in in the half hour I was walking to the office) Looking at the new retro-look and the color look side-by-side (*, sic) I strongly prefer the colorized sbs. If I could have only one that would be the one I would go for. If both looks get their own strong following then it might be advisable to have an admin setting in the repository to choose which of the looks to show. (Ad *): http://core.tcl.tk/tk/ci/1cb7c1e06a?sbs=1 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ 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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.comwrote: On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement. -- Dmitry Chestnykh http://www.codingrobots.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Retro side-by-side diffs
On Fri, Feb 3, 2012 at 11:56 AM, Andreas Kupries andre...@activestate.comwrote: On 2/3/2012 7:25 AM, Richard Hipp 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/21695c3476http://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? (At this point I haven't looked at all the other responses which seem to have gotten in in the half hour I was walking to the office) Looking at the new retro-look and the color look side-by-side (*, sic) I strongly prefer the colorized sbs. If I could have only one that would be the one I would go for. If both looks get their own strong following then it might be advisable to have an admin setting in the repository to choose which of the looks to show. The design of the diff system is such that it would be a major (and undesirable) change to provide support for both side-by-side diff formats. (Ad *): http://core.tcl.tk/tk/ci/**1cb7c1e06a?sbs=1http://core.tcl.tk/tk/ci/1cb7c1e06a?sbs=1 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ P: 778.786.1122 F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/** stackato http://www.activestate.com/stackato __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@gmail.com wrote: On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.com wrote: On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement. Anything that takes so long you have to update between ready/completed states takes long enough you really ought not to be working without a net, uh, SCM. Either work on a branch and merge, or disable autosync, work locally and pull. Then merge back (or push) when it's ready and updated. mike ___ 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 rm followed by unix rm followed by update and files come back, is this desirable?
I think part of the original post was whether the documentation was correct. i.e., it says uncommitted changes are retained. I would argue that fossil rm is an uncommitted change, which should be retained. Either the documentation is wrong or there is a bug w.r.t. fossil rm. As a work around, you could try using '-n' to do a dry run, and see if there is actually anything to update. Tomek On Fri, Feb 3, 2012 at 12:06 PM, Mike Meyer m...@mired.org wrote: On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@gmail.com wrote: On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.com wrote: On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote: If I do: fossil rm some/file.txt rm some/file.txt fossil commit People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement. Anything that takes so long you have to update between ready/completed states takes long enough you really ought not to be working without a net, uh, SCM. Either work on a branch and merge, or disable autosync, work locally and pull. Then merge back (or push) when it's ready and updated. mike ___ 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 rm followed by unix rm followed by update and files come back, is this desirable?
On Fri, Feb 3, 2012 at 11:18 AM, Matt Welland estifo...@gmail.com wrote: If I do: fossil rm some/file.txt rm some/file.txt ...do stuff... fossil update then some/file.txt is resurrected which is really really annoying when you just got your build to work and then because files that shouldn't be there suddenly reappear and things break. I consider this a really obscure corner case. In 4.5 years of using Fossil intensively, this has never come up for me, that I recall. Furthermore, a fix will be tricky, since the code in question has to take into account things such as symbolic links to files that have been removed, files that have been renamed rather than deleted, files for which you have done fossil rm but not rm, files for which you have done rm but not fossil rm, and so forth, and so on. There is a minefield of potential new and more serious bugs lurking here. One must move cautiously. I'll see what I can do. But honestly, this needs to be a low-priority issue. I can see where might be some controversy in the behavior of fossil update in this situation. Is there a good practice that avoids the hassle from the files coming back? I've been telling folks to update often to stay in sync and in this case that can cause annoyance and time wasting. The one possible methodology I can see is to use stash but it seems both overly complicated and actually this behavior seems to violate this phrase in the fossil update help Any uncommitted changes are retained and applied to the new checkout. : fossil rm some/file.txt rm some/file.txt ...do stuff... fossil stash fossil update fossil stash pop ___ 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] documentation clarification
On Feb 1, 2012, at 15:18 , Chris Peachment wrote: I can't speak for MS-Windows or MacOS but Ubuntu Linux uses NTP by default. So does OS X. 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
Re: [fossil-users] Retro side-by-side diffs
On Fri, Feb 3, 2012 at 6:33 PM, Weber, Martin S martin.we...@nist.govwrote: 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. If not color coded, perhaps adding add/change/remove markers to the _start_ of each line, since that would make JS-scripting the colorification relatively simple? (Loop over the lines, do a regex check on the start (change type + line number), and wrapping the affected line(s) in a styled span.) :-? -- - 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] Retro side-by-side diffs
I'd be happy with Stephan's suggestion, since it would satisfy both parties with a little work on the colorizing side. I think the only additional point is to have the div or whatever surrounds the code to have a good descriptive class we can latch on to with JS. Tomek On Fri, Feb 3, 2012 at 12:40 PM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Feb 3, 2012 at 6:33 PM, Weber, Martin S martin.we...@nist.govwrote: 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. If not color coded, perhaps adding add/change/remove markers to the _start_ of each line, since that would make JS-scripting the colorification relatively simple? (Loop over the lines, do a regex check on the start (change type + line number), and wrapping the affected line(s) in a styled span.) :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Retro side-by-side diffs
On 02/03/12 18:40, Stephan Beal wrote: I'm for color-coded. All of the reasons have already been listed in the thread. Same here. If not color coded, perhaps adding add/change/remove markers to the _start_ of each line, since that would make JS-scripting the colorification relatively simple? (Loop over the lines, do a regex check on the start (change type + line number), and wrapping the affected line(s) in a styled span.) I wouldn't like that change very much. I think the way and are used now is very intuitive, and it creates a nice separator column with relevant meta data. I think it would be changing something which is more intuitive to something less intuitive (for the human reader), just to make it easier to regexp, which I don't really like. With that being said, it's just a personal preference, and not something I'd put up a fight against. Though it occurs to me that if almost everyone will anyways be sticking colorized diffs into their fossil repositories via javascript hacks, then perhaps it should be able to output them without any additions. :-/ When I started working on side-by-side diffs it was suggested to me that it could be done using javascript instead, but I thought to myself If everyone is going to be pasting these javascripts (or references to them) into every project they have, it's the sort of feature fossil should handle itself.. How much work would it be to put together a proof-of-concept sbsdiff colorizer? (I would do it myself, but I'm sorry to say my javascript-fu is so weak that I wouldn't even be able to assist anyone wanting to take on the project). -- Kind regards, Jan Danielsson ___ 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 clone produces corrupted repository
Hi List, I am using fossil version-1.21 on Linux Ubuntu-10.04 and am getting weird corruption of the cloned repository. If you would like to reproduce the problem you can download the repository from: http://www.panix.com/~leor/fos/fos.fossil.bz2 Username: fossil Password: fossil-scm Here is what I did: (1) Cloned fossil-scm.org repository into fos.fossil (2) Created a couple of private branches LR.prv and LR-search-prv and played a little bit with the code on those private branches. (3) Looked at public branch exp-search in fossil ui and saw handful of commit from 2010. So far so good. (4) Cloned my repo: $ fossil clone fos.fossil fos2.fossil All my private branches are gone as expected. Now in the cloned repo fos2.fossil the old *public* branch exp-search is not accesible anymore. Neither as a branch nor as a tag. The corresponding commit artifacts seem to be empty. For instance /artifact/0fd61810c4 is empty in fos2.fossil but it is a manifest in fos.fossil (leaf of the exp-search branch) How come that my playing with private branches affected an old *public* branch with the commits from 2010? Did I do something badly wrong or it is a fossil's problem? Any help or/and advise is greatly appreciated! --Leo-- P.S. The same problem happens if instead of clone I remove private branches with fossil scrub --private ___ 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
On Fri, Feb 3, 2012 at 8:17 PM, Jan Danielsson jan.m.daniels...@gmail.comwrote: I wouldn't like that change very much. I think the way and are used now is very intuitive, and it creates a nice separator column with i agree but having them in the middle makes it literally impossible to reliably determine where/what the change-markers are using script code because they can be syntactically ambiguous with content. How much work would it be to put together a proof-of-concept sbsdiff colorizer? The new diffs can't reliably be colored using JS because of potential syntactic ambiguities. It would work often but not always. -- - 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] Retro side-by-side diffs
On Fri, Feb 03, 2012 at 08:33:41PM +0100, Stephan Beal wrote: How much work would it be to put together a proof-of-concept sbsdiff colorizer? The new diffs can't reliably be colored using JS because of potential syntactic ambiguities. It would work often but not always. The sbs diffs come by a 'pre' and the dump of diffs in text form, without any browser-friendly semantic information. I imagine that a similar look could be achieved with tags in the middle, instead of 'pre', and CSS. Fossil knows the semantic information of any symbol it outputs at the time of sbs diff, and it could add or not add the tags depending on ui or console behaviour. Those tags could have meanings for the browser, so it could use CSS to make them look like Richard likes, or like others may like. Would this be enough? Maybe Richard also relies on some ability to 'copy-and-paste' that text, that thus could be broken using the tags. What's bad in using a combination of tags and css in the ui output? The code in fossil looks too complex for too little win? Or simply noone wrote it still? Regards, Lluís. ___ 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 clone produces corrupted repository
On Fri, Feb 3, 2012 at 8:23 PM, Leo Razoumov slonik...@gmail.com wrote: Now in the cloned repo fos2.fossil the old *public* branch exp-search is not accesible anymore. When i try this exp-search is still visible under the branches list, but i see no commits for it. For instance /artifact/0fd61810c4 is empty in fos2.fossil but it is a manifest in fos.fossil (leaf of the exp-search branch) that happens for me, too. How come that my playing with private branches affected an old *public* branch with the commits from 2010? Did I do something badly wrong or it is a fossil's problem? Something wrong apparently happened. i unfortunately cannot venture a guess as to what went wrong, but i can confirm the behaviour on my system (using the latest fossil trunk). -- - 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] fossil clone produces corrupted repository
On Fri, Feb 3, 2012 at 14:41, Stephan Beal sgb...@googlemail.com wrote: On Fri, Feb 3, 2012 at 8:23 PM, Leo Razoumov slonik...@gmail.com wrote: Now in the cloned repo fos2.fossil the old *public* branch exp-search is not accesible anymore. When i try this exp-search is still visible under the branches list, but i see no commits for it. That's exactly what I see. The branch exp-search is listed but clicking on it leads nowhere. Also you can see a tag tmp-1 that is placed on one the commits in exp-search. in fos2.fossil this tag points to a non-existing artifact. --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] [PATCH] Misc fixes for makedeb.sh script.
I installed the fossil package from the Ubuntu repository, but it was
quite old, so I decided to update from source. However, I encountered a
couple issues when trying to generate the .deb, mainly, the official
package is named fossil and the makedeb.sh script creates fossil-scm.
This creates a conflict for /usr/bin/fossil that the package manager does
not like. Additionally, the package was created as i386 even though I use
an amd64.
I created a patch (available below) for the makedeb.sh script that fixes
these issues. The debs that are generated now gracefully update the
official Debian package rather than conflict with it.
Alternatively, I'll probably run my server for a little while in case
someone wants to pull instead.
http://jayschwa.net:8080/info/2be6a56da9
- Jay
Index: debian/makedeb.sh
==
--- debian/makedeb.sh
+++ debian/makedeb.sh
@@ -1,21 +1,19 @@
#!/bin/bash
# A quick hack to generate a Debian package of fossil. i took most of this
# from Martin Krafft's The Debian System book.
DEB_REV=${1-1} # .deb package build/revision number.
-PACKAGE_DEBNAME=fossil-scm
+PACKAGE_DEBNAME=fossil
THISDIR=${PWD}
if uname -a | grep -i nexenta /dev/null; then
# Assume NexentaOS/GnuSolaris:
-DEB_PLATFORM=nexenta
DEB_ARCH_NAME=solaris-i386
DEB_ARCH_PKGDEPENDS=sunwcsl # for -lsocket
else
-DEB_PLATFORM=${DEB_PLATFORM-ubuntu-gutsy}
-DEB_ARCH_NAME=i386
+DEB_ARCH_NAME=$(dpkg --print-architecture)
fi
SRCDIR=$(cd ..; pwd)
test -e ${SRCDIR}/fossil || {
echo This script must be run from a BUILT copy of the source tree.
@@ -41,11 +39,11 @@
rm -fr DEBIAN
mkdir DEBIAN
PACKAGE_VERSION=$(date +%Y.%m.%d)
PACKAGE_DEB_VERSION=${PACKAGE_VERSION}-${DEB_REV}
-DEBFILE=${THISDIR}/${PACKAGE_DEBNAME}-${PACKAGE_DEB_VERSION}-dev-${DEB_ARCH_NAME}-${DEB_PLATFORM}.deb
+DEBFILE=${THISDIR}/${PACKAGE_DEBNAME}-${PACKAGE_DEB_VERSION}-dev-${DEB_ARCH_NAME}.deb
PACKAGE_TIME=$(/bin/date)
rm -f ${DEBFILE}
echo Creating .deb package [${DEBFILE}]...
@@ -87,15 +85,15 @@
true {
CONTROL=DEBIAN/control
echo Generating ${CONTROL}...
cat EOF ${CONTROL}
Package: ${PACKAGE_DEBNAME}
-Section: devel
+Section: vcs
Priority: optional
Maintainer: stephan beal step...@s11n.net
Architecture: ${DEB_ARCH_NAME}
-Depends: libc6-dev ${DEB_ARCH_PKGDEPENDS+, }${DEB_ARCH_PKGDEPENDS}
+Depends: libc6 ${DEB_ARCH_PKGDEPENDS+, }${DEB_ARCH_PKGDEPENDS}
Version: ${PACKAGE_DEB_VERSION}
Description: Fossil is a unique SCM (Software Configuration Management) system.
This package contains the Fossil binary for *buntu/Debian systems.
Fossil is a unique SCM program which supports distributed source control
management using local repositories, access over HTTP CGI, or using the
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] BUG REPORT: fossil clone drops commits, artifacts
Hi Richard, I am afraid I found a bug in fossil scm version-1.21. Clone operation drops relevant commits and artifacts in a public branch causing loss of data. Please, find below a minimal case that demonstrates the bug on Linux (Ubuntu-10.04). For your convenience I wrapped the commands into a shell script bug.sh Put it in a temporary directory and run it. %% File: bug.sh %% #!/bin/sh -e rm -rf fossil-bug # remove playground if existed mkdir fossil-bug # create playground cd fossil-bug fossil new F.fos# created new fossil repo mkdir F cd F fossil open ../F.fos echo my little file F fossil add F fossil ci -m 'Added file F' fossil bra new trunk.prv trunk --private # new private branch trunk.prv fossil co trunk.prv # switch to trunk.prv # make a clone cd .. fossil clone F.fos F2.fos cd .. fossil ui fossil-bug/F2.fos echo ** echo ** Please, observe that file F together with its commit DISAPPEARED echo ** from public trunk in fossil-bug/F2.fos repository echo ** #EoF %%% --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] BUG REPORT: fossil clone drops commits, artifacts
On Fri, Feb 3, 2012 at 5:36 PM, Leo Razoumov slonik...@gmail.com wrote: Hi Richard, I am afraid I found a bug in fossil scm version-1.21. Clone operation drops relevant commits and artifacts in a public branch causing loss of data. Please, find below a minimal case that demonstrates the bug on Linux (Ubuntu-10.04). For your convenience I wrapped the commands into a shell script bug.sh Put it in a temporary directory and run it. Thanks for the bug report and the script for reproducing it. The problem is in the branch new -private command. You can see the problem if you run: fossil test-integrity F.fos %% File: bug.sh %% #!/bin/sh -e rm -rf fossil-bug # remove playground if existed mkdir fossil-bug # create playground cd fossil-bug fossil new F.fos# created new fossil repo mkdir F cd F fossil open ../F.fos echo my little file F fossil add F fossil ci -m 'Added file F' fossil bra new trunk.prv trunk --private # new private branch trunk.prv fossil co trunk.prv # switch to trunk.prv # make a clone cd .. fossil clone F.fos F2.fos cd .. fossil ui fossil-bug/F2.fos echo ** echo ** Please, observe that file F together with its commit DISAPPEARED echo ** from public trunk in fossil-bug/F2.fos repository echo ** #EoF %%% --Leo-- -- 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] BUG REPORT: fossil clone drops commits, artifacts
On Fri, Feb 3, 2012 at 5:36 PM, Leo Razoumov slonik...@gmail.com wrote: Hi Richard, I am afraid I found a bug in fossil scm version-1.21. Clone operation drops relevant commits and artifacts in a public branch causing loss of data. Please, find below a minimal case that demonstrates the bug on Linux (Ubuntu-10.04). Would that all bug reports came with an minimal case test script like this!!! Double thanks! Problem now fixed here: http://www.fossil-scm.org/fossil/vinfo/034e887c35 For your convenience I wrapped the commands into a shell script bug.sh Put it in a temporary directory and run it. %% File: bug.sh %% #!/bin/sh -e rm -rf fossil-bug # remove playground if existed mkdir fossil-bug # create playground cd fossil-bug fossil new F.fos# created new fossil repo mkdir F cd F fossil open ../F.fos echo my little file F fossil add F fossil ci -m 'Added file F' fossil bra new trunk.prv trunk --private # new private branch trunk.prv fossil co trunk.prv # switch to trunk.prv # make a clone cd .. fossil clone F.fos F2.fos cd .. fossil ui fossil-bug/F2.fos echo ** echo ** Please, observe that file F together with its commit DISAPPEARED echo ** from public trunk in fossil-bug/F2.fos repository echo ** #EoF %%% --Leo-- -- 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] minor doc patch, .fos suggestion
hi there, reading through the documentation i thought some sentences would be easier to read with some minor changes, and i also removed end of line whitespace. the other item from the subject concerns the future change of '_FOSSIL_' to '.fos'. i am totally new on the list, so i am not familiar with the debate (if any happened) regarding this change, but the linguistic issue is that 'fos' in hungarian means a certain type of excrement.. i dont know if this is open to discussion, but if it were, i'd say '.fossil' would not be a good choice, as it looks like a repository without a name. '.fockout' would have it's own problems in english ;} so seeing that it's also part of fossil, also an sqlite db file, why not have something less mystical, bit more verbose (being hidden anyway), like '.checkout.fossil' or some such? in the worst case please keep _FOSSIL_ around for us hungarians :] -f Index: www/tech_overview.wiki == --- www/tech_overview.wiki +++ www/tech_overview.wiki @@ -6,11 +6,11 @@ h21.0 Introduction/h2 At its lowest level, a Fossil repository consists of an unordered set of immutable artifacts. You might think of these artifacts as files, since in many cases the artifacts exactly correspond to source code files -that are stored in the Fossil repository. But other control artifacts +that are stored in the Fossil repository. But other control artifacts are also included in the mix. These control artifacts define the relationships between artifacts - which files go together to form a particular version of the project, who checked in that version and when, what was the check-in comment, what wiki pages are included with the project, what are the edit histories of each wiki page, what bug reports or tickets are @@ -17,29 +17,27 @@ included, who contributed to the evolution of each ticket, and so forth, and so on. This low-level file format is called the global state of the repository, since this is the information that is synced to peer repositories using push and pull operations. The low-level file format is also called enduring since it is intended to last for many years. -The details of the low-level, enduring, global file format +The details of the low-level, enduring, global file format are [./fileformat.wiki | described separately]. This article is about how Fossil is currently implemented. Instead of dealing with vague abstractions of enduring file formats as the -[./fileformat.wiki | that other document] does, this article provides -some detail on how Fossil actually stores information on disk. +[./fileformat.wiki | other document] does, this article provides +some detail on how Fossil actually stores information on disk. h22.0 Three Databases/h2 -Fossil stores state information in +Fossil stores state information in [http://www.sqlite.org/ | SQLite] database files. SQLite keeps an entire relational database, including multiple tables and indices, in a single disk file. The SQLite library allows the database files to be efficiently queried and updated using the industry-standard -SQL language. And SQLite makes updates to these database files atomic, -even if a system crashes or power failure occurs in the middle of the -update, meaning that repository content is protected even during severe -malfunctions. +SQL language. SQLite updates are atomic, so even in the event of a system +crash or power failure the repository content is protected. Fossil uses three separate classes of SQLite databases: ol liThe configuration database @@ -48,11 +46,11 @@ /ol The configuration database is a one-per-user database that holds global configuration information used by Fossil. There is one repository database per project. The repository database is the -file that people are normally referring to when they say +file that people are normally referring to when they say a Fossil repository. The checkout database is found in the working checkout for a project and contains state information that is unique to that working checkout. Fossil does not always use all three database files. The web interface, @@ -134,11 +132,11 @@ instead of a dot) and is located in the directory specified by the LOCALAPPDATA, APPDATA, or HOMEPATH environment variables, in that order. h32.2 Repository Databases/h3 -The repository database is the file that is commonly referred to as +The repository database is the file that is commonly referred to as the repository. This is because the repository database contains, among other things, the complete revision, ticket, and wiki history for a project. It is customary to name the repository database after then name of the project, with a .fossil suffix. For example, the repository database for the self-hosting Fossil repository is called fossil.fossil @@ -145,11 +143,11 @@ and the repository database for SQLite is called sqlite.fossil.
