Re: [fossil-users] File contains invalid UTF-8, but is not UTF-8.
2014-07-09 0:05 GMT+02:00 Andy Bradford amb-fos...@bradfords.org: Or perhaps just making the documentation more clear that all files must be valid UTF-8. Oh no, fossil doesn't require at all that all files are valid UTF-8. Only fossil ui assumes UTF-8 encoding for non-binary files, otherwise it cannot display the file content in a reasonable way to the user. If the file is not UTF-8, it just might look strange in the UI, that's all. I added the possibility to convert file to a valid UTF-8 stream when doing a fossil commit. That will not always be what's desired, fossil will convert è (0xe8) to è (0xc3 0xa8) for you if you answer 'c' to the prompt. If you want something else (e.g. escaping) fossil cannot do that for you. Regards, Jan Nijtmans ___ 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 extras] versus symlinks
2014-07-10 5:02 GMT+02:00 Timothy Beyer bey...@fastmail.net: I agree that is a terrifying behavior for the clean command, at least as a default (and _ESPECIALLY_ without undo). There is an undo-clean branch in fossil which implements an undo-able fossil clean: http://fossil-scm.org/index.html/timeline?r=undo-clean The caveat is that the _FOSSIL_ database might become very big, when cleaning big files. And I never fossil cleaned a file by accident (even though I use fossil clean a lot ...) otherwise I might have pushed harder to get this into trunk ;-) I think the larger issue is that clean is a pretty dangerous command in general, and probably isn't what most people want (I find addremove to be much safer), in almost any circumstance. I would go so far to say that it might be for the best if the clean command were removed from fossil altogether. -1 No, no, please don't remove fossil clean. Actually, fossil clean is not dangerous because it prompts for each file before it is deleted. It's the -f|--force option which is dangerous, or pressing 'a' after the prompt. People are getting lazy after having to respond to so many prompts, that's what limits the usability of fossil clean. I use it a lot! Regards, Jan Nijtmans ___ 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] /info/ versus /ci?name=
Re name=... Vs /name... Historical - initially for the wiki api, but happens at the lowest level of args handling, so all pages except the json api inherit it. - stephan Sent from a mobile device, possibly from bed. Please excuse brevity and typos. On Jul 10, 2014 5:42 AM, Andy Goth andrew.m.g...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 What is the difference between the /info/ and /ci?name= URLs? When followed by a check-in artifact ID or unambiguous prefix thereof, it seems the only difference is /ci?name= shows diffs and /info/ merely offers to show diffs. The problem I have is using the edit link on /info/ returns me to the corresponding /ci?name= URL when I apply or cancel. It's rather jarring to start at a page not showing diffs, go edit something, then be returned to a page showing diffs. Actually it can be more than jarring. A few of my commits are monstrously large with diffs that are dozens of megabytes or larger, so of course I wouldn't want to see all those diffs. But nevertheless, they are pushed in my face after doing an edit check-in operation. I know it can be tricky for the edit page to return to the same diff options (hide/unified/side-by-side, show/ignore whitespace), so the easy way out, which I would be happy with, would be to always return to the /info/ page which hides diffs but makes them easy to obtain again. By the way, I also find it curious that /info and /ci can be followed either by /ARTIFACT_ID or by ?name=ARTIFACT_ID with the same result. Is there any particular reason why both are supported? I also see that these two styles are used by different parts of the Fossil UI. Is there an explanation for this apparent inconsistency? - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvguFAAoJELtYwrrr47Y4AhQH/2Y/i+t6NDh7i14H1tno9BfA +7nqarD83/QdqyqWUP5+P23RbET/BqoqTW0BFafF6V2Z7UvvgOE2o1bSflg7TgXt x17ymscDfUTl9O+fLOacNHy5sK/K8xQHT0K5ii0UMrefgw3ZpPLEvAXPAOB4uv9/ v+T78KtkHxO0yglSYCA5MsNIxqbkki6uKxaTYhAQNg4mZRpGTOiN9+sT7ac4nCuQ Fg4XpHPHLAiWpG6sGFiSSVnn46D7ZGBm0K21E0dLkKyVJOGD0oOXVm+OJ1divxuI 9wepvkWAtarev20sft1fptHOrfEBBfcO+dQFkh0OJhzPQdJEOhEUAUQO7mfGnLQ= =GscD -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 extras] versus symlinks
What is allow-symlinks set to for you? From context it sounds like it is set to yes. If so this is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option that is default and should not even exist [i] ) then I think what you are seeing is the expected behavior. [i] In my opinion what you put in to a revision control system should *always* equal what you get out. The default fossil behavior of treating symlinks as extensions to the file tree fundamentally violates this principle. No need to debate this again. The fossil devs are adament that this is what they want but for the context of this discussion I wanted to mention my views on this point again. On Wed, Jul 9, 2014 at 12:23 PM, Andy Goth andrew.m.g...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In one project tree I have a symlink pointing to a directory outside of the checkout directory. [fossil extras] lists all the files in the referenced directory as extras even though they are not actually part of the checkout. I think they should be omitted. According to the -n option, [fossil clean] would remove the files. That's rather serious. I think symlink handling needs to be reevaluated. Symlinks to files and directories outside the checkout definitely need to not have the effect of the referenced files be treated as if they were part of the checkout. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvZaWAAoJELtYwrrr47Y4gtMH/01FYqNHdXIRXVdY3weMsk73 bXIl5Ud3FRBedRAPNoPEam5NGqFwkS+jGdZFWZqa7mM+xif37tuARtnEqGuIdzUi SDcVNsBggENWA4YxlIiYBjL5Ds9Q3sOq7Vt2wvRPrzD7cLwntatn4uKfOH69VPFW cIcB0aDIWEzVgFN2p29uaONnJQyLWB1A9fYFOgGr5VruZcSYkdYMb5PI7C1pmYw3 zAiq79DAeykP1oxeH158mnG5Cgwu7GWRHkNjFIRWW34E5AHxITyCfXdMD5YeVlNa YitbhISlA0rr4Cavsyn0DOdljj26uGOP5R3yI9y4iM9Hr2jGZC+ZawZzXwjXQlM= =V7hm -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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Forks are fun.
I'd like to make life a little easier for the people using fossil here. There are some behavioral changes that can be made (do more work on branches for example) but it would be nice if this could be improved. Three unintentional forks here caused some unnecessary ugliness on the timeline. Forking fun: -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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 extras] versus symlinks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 10, 2014 at 9:52 AM, Matt Welland estifo...@gmail.com wrote: What is allow-symlinks set to for you? From context it sounds like it is set to yes. If so this is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option that is default and should not even exist [i] ) then I think what you are seeing is the expected behavior. It wasn't set at all. I set it to 1 and now Fossil no longer follows the symlink. I'm okay with this. The default is 0 (no) which is what I was getting. 1 (yes) is the fix. On 7/10/2014 12:01 PM, Matt Welland wrote: An additional comment: did you perhaps have allow-symlinks set to 1 in one clone? I hadn't set it anywhere and was not aware of this setting's existence. The allow-symlinks is either flakey or not sticky (I don't recall which) and you have to set it anew on every clone. It is versionable, but I don't have a .fossil-settings directory. I don't think I should add one either because this is actually not natively a Fossil project, but rather one (mis-)managed by ClearCase. I'm just using Fossil on top of ClearCase to help inject a little sanity into the system. Adding files into ClearCase is normally difficult, but in our organization it requires us lowly engineers to petition the head of the CM department in order to add a file. It's unbelievable. I suppose I could start putting files into Fossil that I'm never going to ask to be added to ClearCase, but this could get dangerous. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvt2UAAoJELtYwrrr47Y4gE4IAJrXrPafeyvGGMhJrs8R2Kdj UjwxrExOFzlQ0QmCdbj/xvzQ/eRXYAccmqPa8KN9jHzg2Zyh8dSmnkqQVYdUmr9b U3gAj/T6theKoXDNw5Q8WPxeHuTXMY+7rbXMK6SgVycfguI6BYC4ZvUJhptOy7J8 E/kumwYDBjtGIFkerRfQ2y9LmThwkyqrUZJw/TSl076JpAj+o8sJHmSgM2VQ+s/f 1FUqQxs02HIxu+glr/pVDITUgeNHL1Ura+3ihM64emA/F78+3QYe1Wx29xUYSAN/ fzKvrZD/DAsjj0Nsd4LSwqhC83t9fDzBXjXbNQ+OcN2l+1Vs1XSMlAQdmzZgmNw= =t68w -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] [fossil extras] versus symlinks
On Thu, Jul 10, 2014 at 11:38 AM, Andy Goth andrew.m.g...@gmail.com wrote: It is versionable, Ha! I can't believe I didn't think of taking advantage of this! I'll have to look at how to build creating the .fossil-settings dir + appropriate files into the fsl wrapper on creation of a new fossil. Thanks -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Unusual timeline
On Thu, Jul 10, 2014 at 7:12 PM, Matt Welland estifo...@gmail.com wrote: I find that forks are surprisingly disconcerting to casual users of fossil. A common scenario is that a fork occurs and then developers spin their wheels in silly I already committed this! But I did and update and I don't see your changes! cycles. As Richard has pointed out wise developers who maintain situational awareness by checking the timeline regularly are only trivially affected by forks. FWIW, a bit of trivia: back in 2008 (IIRC) we had an accidental, unnoticed fork or two, one of them being me and Richard a few seconds apart from one another. IIRC (possibly incorrectly) that was what spawned autosync. I have a suggestion that might make life easier for the casual fossil user. On detection of a fork it would be nice if fossil prompted the user to either automerge or autobranch. In automerge fossil would do a merge and if there are no conflicts automatically commit with a comment automerged fork. In autobranch fossil would simply name one side of the fork. Based on other recent discussions, i think you'll find that commit before testing fails a basic sanity check for the majority of the devs. For autobranch, you basically mean what it does now, except that it would pick a new name for the forked one, right? (e.g. username-autofork, or whatever) Note also that if you detect a fork it is important to do a fossil update trunk (assuming the fork is on the trunk) before merging. Otherwise your current node may not be the latest. Update without the branch name seems to not try to move to the latest node. i think(?) that might be because that once the potential fork is detected, sync is stopped. The manual update would not care about a local pending fork. It should work doing fossil update without a branch name, though, i think. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ 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 extras] versus symlinks
On Thu, Jul 10, 2014 at 8:57 PM, Matt Welland estifo...@gmail.com wrote: Ha! I can't believe I didn't think of taking advantage of this! I'll have to look at how to build creating the .fossil-settings dir + appropriate files into the fsl wrapper on creation of a new fossil. That actually sounds like an interesting idea for a 'new' flag: --versionable, which automatically creates .fossil-settings/(some set of properties)... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At work we use ClearCase version tree merge arrows to visually indicate what Fossil calls cherrypick and backout merges. For a cherrypick merge, we draw a merge arrow from the contributor version(s) to the new version. For a backout merge, we tend to draw a merge arrow from the version just before the contributor. For whole-branch merges, we draw from the last version of the contributing branch. Of course there is ambiguity, but the presence of merge arrows clearly indicates that a merge of some sort took place, and the check-in comment tells what is meant by them. This is very helpful for glancing at a tree and seeing which projects picked up bits and pieces of stuff from which other projects, where projects are represented by separate branches but otherwise sharing files. Fossil doesn't quite operate this way. It has very easy merging, and it gives good visual indication of merging entire branches, but there's no visual for cherrypick and backout merges. The check-in comment can name the (positive or negative) contributor version(s), and those names are clickable links in the UI. But that's not quite enough, in my opinion. I want to see something in the timeline plot showing cherrypicks and backouts. Dotted, dashed, and/or colored lines might do the job. I also want to see the origins of cherrypicks and backouts listed in the family, ancestors, and both timeline links on the check-in info page. Let me make a request. If this feature is added to Fossil, I would like it to be possible to edit the cherrypick and backout merge arrows after the commit is complete, in the same way it's possible to edit tags. (Perhaps this could be implemented as special tags rather than as a new card type.) Many times while researching old code I've found engineers weren't always careful with documenting where they got code from, and I was glad I could add (or correct) merge arrows years after the fact so that we wouldn't have to repeat my research to determine the origins of everything. Knowing the genesis of every part of the code is quite helpful, for instance to find the original requirements, user desires, supporting documentation, test procedures, or responsible engineers. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvuk9AAoJELtYwrrr47Y4CKoIANdHjSArVKEZeYq4gx+iWZsV 5jrkam5E1hVGX/uIyIdY8+EwBDta77ZLbWEK99bNobD5U1bypX6tKCNclyTiOtWD sPut0KtwhKp2Xf4WjNJpmpAeRGo2j8hXVHBkamGH9Nj+2f8aJd+80O4fFCTResCs OLETnTkZFmDeEU78UyJ/fsTsskrlrG1fEaPnm3ZWP4Ae41k7MUNU6YQ3iTlrqHsm JS+x8gIAjcuslv+e/Ay24c1+1X54BH559fYHID7GTjXeeCwBdz0X8qL/NcLFF1sL LqQuS0/baHyZfXjSOTV++l7HZim2obmyZig8gv8IWEdtEqv5iWo2AuRAAjIwLYE= =oHLx -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] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/2014 2:37 PM, Andy Bradford wrote: Thus said Andy Goth on Thu, 10 Jul 2014 14:27:57 -0500: I want to see something in the timeline plot showing cherrypicks and backouts. Dotted, dashed, and/or colored lines might do the job. I also want to see the origins of cherrypicks and backouts listed in the family, ancestors, and both timeline links on the check-in info page. This has been brought up before (I specifically mentioned that it should be possible given that the cherrypick merge is recorded with a Q-card), but this is probably low priority. :-) I'm putting together a mockup screenshot illustrating a few ideas and motivating this feature, but it's not ready yet. Can I send it to this list as an attachment, or do I have to host it somewhere and link to it? Let me make a request. If this feature is added to Fossil, I would like it to be possible to edit the cherrypick and backout merge arrows after the commit is complete, in the same way it's possible to edit tags. (Perhaps this could be implemented as special tags rather than as a new card type.) I'm not sure how this would work given that the source of the cherrypick is stored in the Q-card and is not alterable thereafter. It would seem to me that it shouldn't be possible for a cherrypick to be incorrect, or there's a bug in Fossil so what sense would there be in being able to edit it? Not all cherrypicks and backouts are done by [fossil merge]. Around here, lots of things are done by hand. Having better tools than what we have could help to improve matters, but there is a lot of inertia, habit, and general unwillingness to learn how to use the available tools as intended. Therefore it won't be possible for Fossil or any other CM system to always automatically know what merges have taken place. I don't know anybody who uses the merge tool that comes with ClearCase, so I really can't expect everyone to consistently use [fossil merge], should we adopt Fossil. What do the Q cards accomplish for cherrypicks and backouts? First off, am I right in assuming that Q + and Q - correspond to cherrypick and backout? Okay, so does this information get used for anything? It doesn't seem to be displayed anywhere outside the manifest. Tags and comments are editable, and this does not confuse Fossil. It knows not only the original tags and comments but also all edits, and it displays the accumulation of edits without losing track of the originals. So I don't see why Q cards can't be edited in the same way. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvvQPAAoJELtYwrrr47Y4zr0H+gPhLCHL6X7lPKCn6mKbYJMO /EdPl6nf3m9Vw4be50cj8uez1ZWxeGEkgjbG6P+/xKdfq6h81O/N6TbFpxZA2tgP kNYbxR1DQzpmC7rVrKcUA7h5j99LpuX32Y0jhgDChuyS1XgE0+y31B8r+JZy7WNC aU+NwJ+t0N2WQL2SS+/Js32C7O7WdegkKvgeuGxGcbqnUEn9up8eL/DTWtD+aFCb 9gSn26yHfsabQ1+jdRupnvBu2kP0YkCOjRyGemtg9vS61TrSBqwtKCM+5jNABI7L uf/f0kvU7WhgtB/47GfyBh6kwLq3MvhWt0Ix9oChMbtb2DoMIp2vAXWsQc6ASNo= =F7bT -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] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/2014 3:14 PM, Andy Goth wrote: I'm putting together a mockup screenshot illustrating a few ideas and motivating this feature, but it's not ready yet. Can I send it to this list as an attachment, or do I have to host it somewhere and link to it? Let's just try it and see. Since the Fossil timeline arrows are constructed using rectangles made with explicitly positioned divs, it would probably be easiest to just set the color of the arrow rather than use dashed and dotted lines. So that's what this mockup does. This representation clearly shows the relationship between branches. It also highlights the fact that commit 58b4 has *not* been merged from trunk into proj2. That's what it means for the arrow in the top left to be green (cherrypick) rather than black (full merge). - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvv2cAAoJELtYwrrr47Y42z4IAK74VHJl4uL7cloWIhciHTju x4z2NhsQqwl5tQ67J1YyDHo0NIalGQxbG16ihzV7xWosmYe+l4+E/tY5kQ3EZohh 80/FI2XqxtDLbvczh3k2mcY/5kR0KXFmQ5Noxzxw+hB73Vl2u+Rla+t/H2FuXKWS jCcxrTCASh7mi8Ugl/c0lP9il2qP2T8oLT4mvfJpxilDpy55UcbTHXW7+V/WOu1e DXSU2kHQ95vBVW1kJUCtEWF2EsUJ/TG6jOumcpO94s4Zx212nG/5Zt7T0erCr/NK z6jIz2B0XEiMNnv1QpcsPQjqBqNxbDWnErzhJXj08P0G8G1NpP77HpQKdxw7o9I= =3Ahu -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] Visual indication of cherrypick and backout merges
Thus said Andy Goth on Thu, 10 Jul 2014 15:14:07 -0500: Not all cherrypicks and backouts are done by [fossil merge]. Around here, lots of things are done by hand. I see what you mean. You're looking for a way to tag something as ``merged'' by copy-paste and not using merge --cherrypick and for the UI to understand this and use an arrow in the timeline to link it up. What do the Q cards accomplish for cherrypicks and backouts? First off, am I right in assuming that Q + and Q - correspond to cherrypick and backout? Okay, so does this information get used for anything? It doesn't seem to be displayed anywhere outside the manifest. As far as I know it just records the predecessor. It isn't currently used by the UI for anything, though I think it could be used to inform the arrow rendering portion of the timeline to draw associations. Tags and comments are editable, and this does not confuse Fossil. It knows not only the original tags and comments but also all edits, and it displays the accumulation of edits without losing track of the originals. So I don't see why Q cards can't be edited in the same way. I see, I think I've misunderstood your proposal. You aren't suggesting that the Q-card stored in the manifest be changed, but that it be allowed to be superceded by another manifest that has different information than the original (this is how propagating tags and edits work). That's a fair question, not one that I think I can address. :-) Andy -- TAI64 timestamp: 400053beff3d ___ 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] Visual indication of cherrypick and backout merges
On Thu, Jul 10, 2014 at 11:01 PM, Andy Bradford amb-fos...@bradfords.org wrote: I see, I think I've misunderstood your proposal. You aren't suggesting that the Q-card stored in the manifest be changed, but that it be allowed to be superceded by another manifest that has different information than the original (this is how propagating tags and edits work). That's a fair question, not one that I think I can address. :-) If that summary indeed reflects the goal, i _think_ it's just a matter of changing the timeline query to do so. Looking at the code now, i see that graph.c is quite a bit more than a timeline parser, though, so maybe it's not as straightforward as changing a query. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Visual indication of cherrypick and backout merges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/10/2014 5:22 PM, Stephan Beal wrote: On Thu, Jul 10, 2014 at 11:01 PM, Andy Bradford amb-fos...@bradfords.org wrote: I see, I think I've misunderstood your proposal. You aren't suggesting that the Q-card stored in the manifest be changed, but that it be allowed to be superseded by another manifest that has different information than the original (this is how propagating tags and edits work). That's a fair question, not one that I think I can address. :-) If that summary indeed reflects the goal, i _think_ it's just a matter of changing the timeline query to do so. Looking at the code now, i see that graph.c is quite a bit more than a timeline parser, though, so maybe it's not as straightforward as changing a query. Yes, this is what I'm going for. (1) Show cherrypicks and backouts in a manner similar to normal merges but using a different color or dash pattern. (2) Allow cherrypicks and backouts to be edited by later manifests the same way comments and tags can be edited. (3) Include cherrypicks and backouts in the ancestor/family/both timelines, the same way merge contributors are shown. Not sure if my image attachment made it to the list, but here's a link to the mailing list archive which may work too: http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/20140710/35580a49/attachment-0001.png The image doesn't show any examples of backouts, but I imagine they could be red. The line/s would come from whichever commit/s is/are being undone. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTvxmmAAoJELtYwrrr47Y4NDYIAKUzDFyQyJ5pjMLpktcpko49 MzWmchZL9q/EhBBdMdWtL4jP8/aK4fA4Z28FsZEPazjsX30Md7WzrguAGC138dX/ ZY7+D9sLScvAK9NJOxsMJ251fjehSlBGqb9n5Bb6ujEf5hF2kKJebtOUZaEfRoIa 3gQMuUv8YrxSFNH5uR0IoQJaUj6+zHygwafXZvRbbmD8SgE3xW+nSSv29+pki/6T DnUQjgQWm4mkL/7KS85h+ArSMH1k05K/mxgupZjivXDUVMUT/0ygBjP17vQ52BFt SfMSAtEYIuQCe1DzeNmgnSvyR3enC/k8o98wSExsipx5qUo/zN7D7yxCXq32kk4= =43ec -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] Visual indication of cherrypick and backout merges
Thus said Stephan Beal on Fri, 11 Jul 2014 00:22:52 +0200: If that summary indeed reflects the goal, i _think_ it's just a matter of changing the timeline query to do so. Looking at the code now, i see that graph.c is quite a bit more than a timeline parser, though, so maybe it's not as straightforward as changing a query. Yes, back when I discovered Q-cards I too looked at graph.c and wondered why it didn't already handle them, but it turned out not to be so simple. Changing the timeline to include Q-cards is one thing, and I think that would be a nice-to-have, but I'm starting wonder if the Q-card As independent of what is being requested. I think the bigger goal is simply to have a way of associating one checkin with another in the timeline and that it is user alterable. Given that the Q-card is actually a reference to a SHA1 of another Manifest (it's just like the P-card except it is only specific to the named SHA1 hashes, and doesn't imply a merge of all ancestry) I don't think it makes much sense to supercede the Q-card. How could the Q-card ever be wrong? Either you typed ``fossil merge --cherrypick'' or you didn't. If you did, it will merge in just that content and include the Q-card[1]. If you didn't, then there will be no Q-card. I think, however, that a special tag that represents a relationship might make more sense and somehow this would help the UI figure out how to draw more lines. [1] It is possible to type ``fossil merge --cherrypick'' and let Fossil merge in content, but then you can remove all the merged in content, and add different content, and the Q-card will still be present. Not sure if this is a bug or simply a case of ``why would anyone ever do that?'' :-) Andy -- TAI64 timestamp: 400053bf2587 ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 17:54:49 +0200, Stephan Beal wrote: i apologize if i gave that impression. i was refering to re-thinking in terms of fixing, as opposed to removing. i would not, in fact, mind if symlink support was dumped (i have always felt it falls outside of fossil's core, but i also know i'm in the minority there), but it can't be removed while retaining compatibility, and people do indeed use it. i have not added it to libfossil yet, but will indeed have to at some point, or risk alienating any repos which use them. No worries. I just wanted to make sure that the developers were aware that there are use cases for it, but perhaps it is not a popular feature, or is at least misunderstood. I use fossil for both software development and sysadmin tasks, and I while I have to admit that I only want to follow symlinks for the latter, it is a huge benefit in that case, and I strongly suspect that people who complain about it just want allow-symlinks set to on in the default configuration, which I wouldn't disagree with (and the way it is worded is counterintuitive). Regards, Tim Disorganization is a constant on my end ;). :) Regards, Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 09:52:13 -0700, Matt Welland wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] What is allow-symlinks set to for you? From context it sounds like it is set to yes. If so this is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option that is default and should not even exist [i] ) then I think what you are seeing is the expected behavior. [i] In my opinion what you put in to a revision control system should *always* equal what you get out. The default fossil behavior of treating symlinks as extensions to the file tree fundamentally violates this principle. No need to debate this again. The fossil devs are adament that this is what they want but for the context of this discussion I wanted to mention my views on this point again. If the user doesn't want the contents of the symlink, then I would make one of the following suggestions: 1) Set allow-symlinks to on, so that it will add the symlinks as files that are not followed, IIRC. This is probably the behavior that the OP wants. I'll admit that this setting should be the default, although I find on to be fairly useless for my applications. 2) Leave allow-symlinks on off, and put any offending symlinks files in the ignore glob, which is particularly useful in the presence of a versioned .fossil-settings/ignore-glob file. I have done this for quite a while, and it has been quite effective and flexible. I don't really understand why people have such strong objections to this method. 3) If adding the file is a genuinely serious issue, consider if the symbolic link should even be in the path of the repository. I'm not trying to play devil's advocate here, but I am curious as to the scenario that the user faces. I assume that they don't have control over what is present in the working directory? (In which case, either #1 or #2 apply). What I don't really understand is, why does a user want the symlink itself? This is likely far less valuable than the data stored inside of the symlink, and likely lacks relevance on other systems. If the symlinks cannot be followed, then how is the user supposed to version data of a portion of the directory hierarchy below the current location? Further, if someone clones the repository on another unix machine, what happens if the path that it points to either doesn't exist, or points to something completely different? Second, versioning the symlink itself, rather than following it seems less portable to me. OSes other than UNIX may not necessarily have symbolic links, so when a user clones that repository from Windows, I'm not sure how the symbolic links would be represented. When they are followed, it just clones the raw files, so I see no portability issues in regard to solution #2. Someone brought up a ClearCase scenario, where the presence of versioned .fossil-settings/ignore-glob is an issue. In this case, I would presume that ClearCase doesn't have a way to exclude fossil centric files? In that case, suggestion #1 applies. But if that is an issue, then why aren't .fslckout and the repository itself issues as well? Tim ___ 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 extras] versus symlinks
It's clear people are split on what The Right Thing To Do is re: symliks. I'm personally not sure; I don't use them in the course of development. That said, I feel like they should *not* be in indirrected-through as a matter of treatment. It's understandable those that _would_ like them to be followed say: they're there, follow them., but what if a link points to /etc? You want to publish your system config files? I feel that as a matter of safety and *fossils* principles (as I understand them), the link should not be interpreted. If you want to make a link that references something in the working root of that repository's view (bounded at its root), then putting it into a repo will not break anything. If you want to access something outside the repo, i'm afraid I think this is bad repo architecture. We already say no to introspection and special-handling for (eg) line endings (Win versus Unix), and this principle of simplicity could be applied to links as well. I feel there are greater inconveniences and security risks with special treatment of links than without. Safety is at risk, and though principle of least surprise seems to be touted by the symlink followers, it can easily be applied to no special treatment for symlinks as well. Interested to witness the discussion though. On Jul 10, 2014 7:29 PM, Timothy Beyer bey...@fastmail.net wrote: At Thu, 10 Jul 2014 09:52:13 -0700, Matt Welland wrote: [1 multipart/alternative (7bit)] [1.1 text/plain; UTF-8 (7bit)] [1.2 text/html; UTF-8 (quoted-printable)] What is allow-symlinks set to for you? From context it sounds like it is set to yes. If so this is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful option that is default and should not even exist [i] ) then I think what you are seeing is the expected behavior. [i] In my opinion what you put in to a revision control system should *always* equal what you get out. The default fossil behavior of treating symlinks as extensions to the file tree fundamentally violates this principle. No need to debate this again. The fossil devs are adament that this is what they want but for the context of this discussion I wanted to mention my views on this point again. If the user doesn't want the contents of the symlink, then I would make one of the following suggestions: 1) Set allow-symlinks to on, so that it will add the symlinks as files that are not followed, IIRC. This is probably the behavior that the OP wants. I'll admit that this setting should be the default, although I find on to be fairly useless for my applications. 2) Leave allow-symlinks on off, and put any offending symlinks files in the ignore glob, which is particularly useful in the presence of a versioned .fossil-settings/ignore-glob file. I have done this for quite a while, and it has been quite effective and flexible. I don't really understand why people have such strong objections to this method. 3) If adding the file is a genuinely serious issue, consider if the symbolic link should even be in the path of the repository. I'm not trying to play devil's advocate here, but I am curious as to the scenario that the user faces. I assume that they don't have control over what is present in the working directory? (In which case, either #1 or #2 apply). What I don't really understand is, why does a user want the symlink itself? This is likely far less valuable than the data stored inside of the symlink, and likely lacks relevance on other systems. If the symlinks cannot be followed, then how is the user supposed to version data of a portion of the directory hierarchy below the current location? Further, if someone clones the repository on another unix machine, what happens if the path that it points to either doesn't exist, or points to something completely different? Second, versioning the symlink itself, rather than following it seems less portable to me. OSes other than UNIX may not necessarily have symbolic links, so when a user clones that repository from Windows, I'm not sure how the symbolic links would be represented. When they are followed, it just clones the raw files, so I see no portability issues in regard to solution #2. Someone brought up a ClearCase scenario, where the presence of versioned .fossil-settings/ignore-glob is an issue. In this case, I would presume that ClearCase doesn't have a way to exclude fossil centric files? In that case, suggestion #1 applies. But if that is an issue, then why aren't .fslckout and the repository itself issues as well? Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 20:10:09 -0700, B Harder wrote: It's clear people are split on what The Right Thing To Do is re: symliks. I'm personally not sure; I don't use them in the course of development. That said, I feel like they should *not* be in indirrected-through as a matter of treatment. It's understandable those that _would_ like them to be followed say: they're there, follow them., but what if a link points to /etc? You want to publish your system config files? The funny thing is that the reason above is exactly why I want that feature. Perhaps one man's junk is another man's treasure. :) I know that a lot of people are going to object and say that fossil is not an appropriate tool for system configuration backups, but in my experience it is ideal for that purpose. My issue as far as The Right Thing To Do (TM) goes is that I'm not convinced either is more correct than the other. Although such a restriction wins in safety, it makes fossil significantly less general purpose, so it loses big in extensibility (notably, for system administration tasks). That is why I think the default should be what you and others advocated, but a non-default option should always be available so as to not artificially restrict domains of usage where fossil turns out to be very useful. Tim ___ 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 extras] versus symlinks
At Thu, 10 Jul 2014 21:31:11 -0700, B Harder wrote: It's certainly not cut and dried :) This has been a fairly thought provoking discussion, as in the process of arguing for symlinks, I'm now questioning why I like them so much for backups (I never use them for any of my development repositories). I'm even starting to think that I could work without them, although if I went that direction, I'd want a lot more scripts to ensure that everything is done consistently for security purposes. Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
