Re: [fossil-users] [fossil extras] versus symlinks
On Fri, Jul 11, 2014 at 1:40 AM, Timothy Beyer bey...@fastmail.net wrote: 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). My team at work uses symlinks for project builds. The down side is that simple symlinks impose limitations on the placement and naming of the referenced workspaces. Fortunately, symlinks can be relative, so the placement rule is simple: $HOME/Project - Workspace naming is more complicated. our solution is that whenever a new baseline is designated for a given project, the updated symlinks are committed. For day-to-day development, local changes to symlinks are not committed. Someone suggested that the build process should create the links. We don't disagree, but we (my team and I) are nowhere near agreeing on how to represent the information required to create those links dynamically. For system configuration management, symlinks do make a lot of sense, whatever VCS is being used. (The IT people where I work use symlinks - even on MS Windows - to make version tracking of system configuration easier.) I do recall reading about a modified SVN client for managing system configuration. IIRC, it allows the .svn directory be placed anywhere, not just at the root of the workspace. Not sure what it would take to enable Fossil to do similar. Presumably, the _FOSSIL_ db file would need to point to the actual workspace root. I suspect it would be necessary to either have a command line option to tell Fossil where the _FOSSIL_ db file is, or to run Fossil from the directory with the _FOSSIL_ db file and use either absolute paths, or paths relative to _FOSSIL_'s directory. ___ 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 Fri, Jul 11, 2014 at 5:47 PM, Ron W ronw.m...@gmail.com wrote: Someone suggested that the build process should create the links. We don't disagree, but we (my team and I) are nowhere near agreeing on how to represent the information required to create those links dynamically. If you're using GNU Make or similar, something like the following would be pretty simple: (this is untested, based on other Make code i happen to have open) define LINK_IT # $1 = symlink name # $2 = file/dir to link $(1): $(2) TABln -sf $(2) $(1) CLEAN_FILES += $(1) endef $(call link1,/etc/hosts) $(call link2,/etc/passwd) ... For system configuration management, symlinks do make a lot of sense, whatever VCS is being used. (The IT people where I work use symlinks - even on MS Windows - to make version tracking of system configuration easier.) But of course the above assumes a fairly homogeneous (i.e. Unix-like) environment. I do recall reading about a modified SVN client for managing system configuration. IIRC, it allows the .svn directory be placed anywhere, not just at the root of the workspace. FWIW: that's one of the things i hope to eventually experiment with in libfossil. The underlying bits are designed to be able to support that but no APIs actually use it because it's quite convenient to reliably know that .fslckout is in the root of the checkout). Not sure what it would take to enable Fossil to do similar. Presumably, the _FOSSIL_ db file would need to point to the actual See above :) -- - 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 Fri, Jul 11, 2014 at 11:56 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Jul 11, 2014 at 5:47 PM, Ron W ronw.m...@gmail.com wrote: Someone suggested that the build process should create the links. We don't disagree, but we (my team and I) are nowhere near agreeing on how to represent the information required to create those links dynamically. If you're using GNU Make or similar, something like the following would be pretty simple: (this is untested, based on other Make code i happen to have open) define LINK_IT # $1 = symlink name # $2 = file/dir to link $(1): $(2) TABln -sf $(2) $(1) CLEAN_FILES += $(1) endef True. Our road block is related to automating finding the targets of the to-be-created symlinks In theory, simple, but in practice, agreeing on the meta data to use and how to represent and store that is currently no time soon. ___ 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] [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
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] [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
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
[fossil-users] [fossil extras] versus symlinks
-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
Re: [fossil-users] [fossil extras] versus symlinks
On Wed, Jul 9, 2014 at 9:23 PM, Andy Goth andrew.m.g...@gmail.com wrote: According to the -n option, [fossil clean] would remove the files. That's rather serious. Doh. Indeed. i'm looking into it now. i know we have a routine which determines if a file is in the checkout (b/c i ported it to libf), but can't remember what it's called. 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. Which commands are most seriously affected? - clean - extras ? i'll start there (no guarantees!). We'll have to make some decisions about warnings and whatnot here. Ideas are welcomed. e.g. extras/clean might(?) want to warn that they're skipping non-checkout files? -- - 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 Wed, Jul 9, 2014 at 9:29 PM, Stephan Beal sgb...@googlemail.com wrote: Doh. Indeed. i'm looking into it now. i know we have a routine which determines if a file is in the checkout (b/c i ported it to libf), but can't remember what it's called. Here we go: /* ** Compute a pathname for a file relative to the root of the local ** tree. Return TRUE on success. On failure, print and error ** message and quit if the errFatal flag is true. If errFatal is ** false, then simply return 0. ** ** The root of the tree is defined by the g.zLocalRoot variable. */ int file_tree_name(const char *zOrigName, Blob *pOut, int errFatal); so everything for a fix is already in place :). Looking into 'clean' now... -- - 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 Wed, Jul 9, 2014 at 9:32 PM, Stephan Beal sgb...@googlemail.com wrote:
so everything for a fix is already in place :). Looking into 'clean' now...
i don't believe clean is affected by this problem:
if( file_tree_name(g.zRepositoryName, repo, 0) ){
db_multi_exec(DELETE FROM sfile WHERE x=%B, repo);
}
sfile is a temp table with the names of files in the list.
--
- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/9/2014 2:29 PM, Stephan Beal wrote: On Wed, Jul 9, 2014 at 9:23 PM, Andy Goth andrew.m.g...@gmail.com wrote: 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. Which commands are most seriously affected? - clean - extras ? addremove perhaps? I've been afraid to experiment because I don't want to jack up my repository. Since this project's awful build process hijacks a bunch of checked-in files during compilation, I've been explicitly listing the filenames I want checked in when running commit. So I'm already having to force Fossil to not just grab every file it thinks is appropriate. Yeah, I definitely want to fix it to not hijack everything, but budget for that sort of improvement is sadly limited. - -- 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/ iQEcBAEBAgAGBQJTvZokAAoJELtYwrrr47Y4U10H/0p692oitOos21RbBE5OTrzy MN7mWLakmh6xyIFNEyBYfxedNxS5wj9Jxh7dqhglm0xpTjvzYI8+jJEu7BaylkRm y/Pze9YB7+nqLlK79fenFmZwj9e14lBIty/D4eSxW8sF/IopRjPVvzqHXpdWAQEV 75ujTgw2Vbd6QPI6VFMtubVov2tgAuAkFIc8TGHV+5hMiadmxUQ6vl+qV6h03M8W CyR09k6cWJMt71tSx2q5rXjDJfVRAcub5KvppYj+Su0m7MJgdH3eHjdedwGM7Tcr GWCqfm+1OvIAxs22IS3f5IZnw3OB3t1EI9CZRYFcdITwXQxrrIB5DSTSsXRHO3Y= =ce98 -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 Wed, Jul 9, 2014 at 9:36 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Jul 9, 2014 at 9:32 PM, Stephan Beal sgb...@googlemail.com
wrote:
so everything for a fix is already in place :). Looking into 'clean'
now...
i don't believe clean is affected by this problem:
if( file_tree_name(g.zRepositoryName, repo, 0) ){
db_multi_exec(DELETE FROM sfile WHERE x=%B, repo);
}
sfile is a temp table with the names of files in the list.
Doh, spoke too soon: file_tree_name() returns 1 if the file name is in the
repo, which means it could potentially be affected. Still looking.
locate_unmanaged_files() seems to be the right place.
--
- 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 Wed, Jul 9, 2014 at 9:38 PM, Andy Goth andrew.m.g...@gmail.com wrote: addremove perhaps? I've been afraid to experiment because I don't want to jack up my repository. Understood. Here's my analysis after implementing an is in repo algo, and i've found the core of the problem: canonicalizing a symink... [odroid@host:~/fossil/fossil]$ ln -s /etc . [odroid@host:~/fossil/fossil]$ f extra | grep etc | head -2 etc/ConsoleKit/seats.d/00-primary.seat etc/ImageMagick/coder.xml those _resolve_ to something under the checkout, so they look like in-checkout files. i.e., the fix requires some thinking at the symlink handling level, not necessarily the is this file in the checkout path level. i currently know little about that code (i've elided symlinks in libfossil so far because i've never liked the idea of fossil supporting them ;). That's the root of the problem, i believe, but it's approaching bed time here, so i'm going to have to ask one of the other devs to take it from there, or wait until tomorrow evening. -- - 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
At Wed, 09 Jul 2014 14:23:02 -0500, Andy Goth 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. I agree that is a terrifying behavior for the clean command, at least as a default (and _ESPECIALLY_ without undo), but I hope that the ability to follow symlinks remains at least as a non-default setting (eg. the ability to set allow-symlinks to off). The reason why I say this is because I depend on following symlinks to back up a lot of different directories in different places on the same machine, eg. for per system back up, but only for the most important parts of that system. Fossil works very well for this task, but if that feature were removed altogether, it would be an incredibly tedious task, and I would otherwise need about 10 times as many repositories, especially at work, where I keep configuration files under version control for over 10 separate machines (from various parts of each system). I'd hate to require nullfs just to have the ability to maintain that workflow. 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. I'm still unsure if fossil delete should literally delete the files as well, although that might be a better workflow for beginners (I'm not endorsing either approach on the latter). Regards, Tim ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
