On 03/11/15 00:38, Scott Robison wrote: >>> On 11/2/15, Jan Danielsson <jan.m.daniels...@gmail.com> wrote: >>>> >>>> Supporting symlinks on Windows would currently be a little mess. >>> >>> What if we just say that symlinks don't work on Windows and that if >>> you include them in your repo, you won't be able to checkout (sanely) >>> on Windows? >> >> I think Fossil should give a best-effort try via UAC, but yeah, if that >> doesn’t work, no tears should be shed about it. >> > > I know I've posted this before, but just to reiterate: > > If you are an unprivileged user, you can create symlinks if you've been > granted the symlink priv. It is not hard to do at all.
Sure, but that means instructing people to change a system policy to be able to check out code in repositories which use symlinks. Unless we pop up a question "Do you want to reconfigure the system to allow symlinks?" if needed, that would be more acceptable to me, but how do we handle domain environments where GPO's are pushed out by the domain controller, and the user can't change that setting? > The problem comes with UAC for unelevated administrative users only, > because Microsoft in their infinite wisdom saw fit to strip symlink privs > from unelevated admin users by default. Agreed. > One: Most windows users wouldn't be using symlinks and wouldn't care. Agreed, again. > Two: It's not hard to have two command prompts open, one running as a non > admin user with symlink privs. One could run fossil from the non admin > user. Or one could easily run fossil as the non admin user that has symlink > privs. This may surprise some of you, but I can point to a large IT consultant firm with thousands of developers world-wide who do _not_ have administrator privileges on their own systems. They simply can't open elevated command line prompts, unless they are driver developers who have been given special privileges due to specific project requirement. I agree it's a theoretical point in this specific discussion, but just reminding that being able to open up an elevated command prompt can actually be a luxury in some environments, so it's not a "catch all" solution in Windows. > Maybe it's not worth doing, and maybe I shouldn't have bothered adding real > symlink support in the winsymlink branch. However, it is possible, and it's > not as onerous as many people are making it out to be. My skepticism boils down to the fact that we can't make a general solution which will work smoothly everywhere[*]. Call it OCD if you will, but I think "We support symlinks on Windows, but not without policy changes to the system and not in these types of special environments." looks a little iffy, considering there are no such caveats on other platforms. That said, like I said earlier, I don't object to anyone willing to give it a shot, and seeing as you already have done it, then there's no sense in me making the argument that it would be better to wait until symlinks on Windows are more polished. I am curious to know though how you get the reparse point, and if you've encountered those hangs. I didn't know about the winsymlink branch, so I'll take a look. [*] In practical terms, as you say, more or less zero users (today) will encounter these problems. As stated; to me it's more the asymmetry which bothers me. -- Kind Regards, Jan _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
