SparkleShare should allow users to set their share folders, for example I have my Dropbox folder on partition D: because C: is reserved for System and Applications. While SparkleShare tells me that it will create a folder for me during installation, it won't let me select where.
i was against this at first, but i've changed my mind because of this use case. sometimes you just need to put the folder somewhere else because of space issues. i've put this on the roadmap for 2.0.
did i missed anything?
the path option works already for me like in #680 described.
but to take up the issue again (only as a proposal):
would it not be skillful to move the .tmp folder by default from the sparkleshare folder to the config folder?
so you don't need a separately sparkleshare folder and you can leave the decision to the user, where they want to create their local git repository.
@Matthis you can change the config option, but there's no UI for this yet. the .tmp folder could be moved to .config, but then you would have the same issue as @mrtnmueller has: limited disk space (and .tmp will contain a temporary copy of the whole project).
oh, i forgot the space issue :)
me personally disturbs the .tmp folder a little bit, because i don't know a good place where i should move it to.
would it not be clever to put this folder hidden into the git repository? or are hidden folders also synced?
@Matthis the .tmp folder is where projects go when first synced, then they are moved into place (one folder up). why does it disturb you? it's hidden by default.
yes i know it's hidden and it shouldn't be a problem,
but i dissolved (is this the right word?) my sparkleshare folder and moved my projects to D:
at the moment i moved my .tmp folder into the config folder on C: and how you said it could become be a space problem ;)
@Matthis moving the .tmp folder won't affect anything. another will just be created in the SparkleShare folder.
i hope not :)
i changed the folders_path to the config folder of course
Hey, hbons! Great piece of software! :D
Glad to see you have changed your mind in regards to changing the location of the SparkleShare directory.
I would really appreciate a feature allowing each project to be placed outside of the SparkleShare directory client-side as I would love to be able to sync a bunch of stuff from all over the 5 drives in my stationary machine. In this case junctions and/or symlinks prove to be ineffective. In Windows SparkleShare accepts one junction per project which is reproduced by the client as a directory, but others added later seems to be ignored.
You've probably heard this request before, but I figured I'd throw it out there in light of your decision to allow moving the SparkleShare directory. :)
@GeirAkslen i don't see a reason to do it, and what are these "junctions" you're speaking of?
Junctions are like symlinks, but for Windows. See: http://technet.microsoft.com/en-us/sysinternals/bb896768.aspx
The reason is pretty much the same as for moving the entire SparkleShare directory. Flexibility for the end user based on their way of organizing information.
In my case, information is spread over different drives in order to get as much IO as possible from the devices containing projects with large files.
Moving these files into the SparkleShare directory will either corrupt application project files and/or break scripts I have put much work into. The scripts can be rewritten, but this means I'll also have to consolidate all my projects to one drive and seriously gimp performance in favor of convenience. In the long run, storage capacity would also become an issue in this scenario.
I would be ecstatic if I could keep my current configuration as is, while placing the SparkleShare projects where I choose as it would really enhance my workflow without hacky solutions which are prone to failure. :)
For instance, junctions works fine with Dropbox as long as a machine isn't unlinked. When the machine is linked to the DropBox account again, it will delete the junction and replace it with a directory containing a copy of whatever is on the server. I haven't gotten as far as to test whether this is the case with SparkleShare.
Perhaps I'll get to it after I've walked the dog. In any case, you'll hear from me as soon as I know.
I'd even prefer to specify any desired location for individual "Projects"...
It would be the same handling as it is usual with network shares, where you can define any arbitrary directory to have it released as network share. This makes sense where different types of projects are intentionally stored in different locations. BTW: .gitignore
..... BTW:. gitignore is a perfect way to exclude subdirectories "below" any project directory (and of course, also files etc.)
I just started using SparkleShare and I love it as a good alternative to DropBox, however I'm disappointed that you're not going to allow us to pick where we want to store each project. At the very least I think there should be support for following symlinks, which it currently does not do (or I couldn't figure out how to make it). I agree that it's mostly about convenience, however I just got done moving all my files (documents, etc.) to my new RAID and got done reconfiguring everything to point to them there. I wasn't expecting that there wouldn't be support for such a seemingly basic thing.
I have made a preliminary version of this feature in the branch at brandondahler/SparkleShare/FolderLocation . It should currently work; however, it is not polished or fully tested.
If anyone has any input on the coding or aesthetics, feel free to comment.
Can't give advice on the coding, but the look is nice!
I'm just starting to test sparkleshare for myself and I couldn't find an option to specify a custom location for the project folder on the server side (as opposed to /home/USER/projects). Is it (already) possible to move this folder to a mounted drive (for the same reason as mentioned before)?
@brandondahler i'm not a fan of any kind of "advanced options" area. a nicer way to do it would be to detect removal of a project from the SparkleShare folder. a dialog would then pop up asking what should happen: [ Remove the project from SarkleShare ] or [ I've moved the project elsewhere ] -> [ Folder Location Selection].
Offering to move things after the fact is less user-friendly than an 'advanced options' area. Let's say I have a 10GB project; I'd have to download all 10GB to (on Windows) %USERPROFILE%\SparkleShare and then move it to a different location. This alternative location may be on a different partition (on the same or a different disk) which means another long wait. And what would happen if the partition that hosts the initial sync doesn't have enough free space?
Always showing a pre-populated 'local folder' field in the setup dialog (instead of one hidden behind an advanced options toggle) would be more user-friendly again.
Indeed the way brandondahler suggests is the best. Select your folder when setting up a project. A move option later on would be a "nice to have" but is not really a top priority as I see it.
@dermotw for that i'm making the location of the SparkleShare folder customisable, which is what this issue was originally about.
But not the location of individual projects? (Not sure that that's a big deal, certainly isn't for me).
@dermotw if we can do it in a non-obtrusive way, i'm fine with the feature. the reason for adding the possiblity of moving the SparkleShare folder right now is a possible lack of disk space where the home folder is.
i don't really see a reason (yet) why individual projects should be movable as well. there are probably edge cases where this could be handy, but i don't want to make it an option in the main UI just for that.
So what you need is an option for setting the location of the SparkleShare folder at install time and a mechanism for moving it later if need be - sounds reasonable to me!
@hbons The main reason I went with the advanced options slider is so that it is as unobtrusive as possible. I just realized that I did not include a label for it.
Just to clarify, the input box only applies to this fetch and will pre-populate again for the next fetch in the current program run. It does not persist between program runs.
Use case for putting project folders all over the place:
Suppose I want to sync a special directory between different computers. Think, for example, my GIMP plugins folder with all my python scripts, or my installed gnome shell extensions. I can't move the directory since its location is fixed, (e.g. in the .config or .gimp directory) so if I want to sync it, i must be exactly in that place.
I don't want to think of SparkleShare as one single entity where all my shared folders are, I want it to be a tool to sync any directory between different computers.
@merlinthered you can create a repo with your gimp config, and symlink it.
True. If this is possible in Windows also, I could be happy with that solution.
I'd like to reopen the case for @merlinthered's putting project folders all over the place. @hbons says to simply create the repo in the Sparkleshare folder, then place a symlink at the location you'd like the folder to be. The problem with that is that if the symlink breaks, your system breaks. I'd rather keep the files at the location they are expected to be by either the OS or the user, than the other way around. Software is supposed to solve problems, not add to them.
@berklee SparkleShare was never made to solve this problem though, it was made to help people collaborate on projects/files. it can't be everything to everybody.
a symlink can break, but so can anything else...
@berklee I don't see any issue with the symlink method. I use symlinks often, in many applications. I'm just not sure what the problem is.
The main problems with symlinks are:
I don't feel like this is as an invasive of a change as it is being made out to be.
@BarryThePenguin I have no issue with using symlinks pointing out of a synced dir; I have an issue with symlinks pointing to a synced dir. If a program does not follow symlinks (or the symlink breaks) in the first case: no problem, everything works as expected. If a program does not follow symlinks (or the symlink breaks) in the second case: nothing works.
Ideally as @brandondahler laid out, no symlinks would be required. Bittorrent Sync does this.
how about a UI that will allow the user to specify the folder for the project - and if that folder is not located under the sparkleshare folder - then sparkleshare will create the symlink?
for users using SparkleShare the ability to select an existing folder to be shared with others is important, they not necessarily interested with how it is being done
Being able to put sparkleshare folders wherever I like would be great. I'd like to have one sparkleshare repo per project to keep our assets synced up. There's very obvious benefits from being able to have sparkleshare manage subdirectories of exisiting file structures - this does not detract from the stated purpose of sparkleshare being aimed at enabling collaboration, in fact, it would make it more useful.
Plus one for local storage selection, it is the same for me:
I have already lots of projects that I want to sync, some are web-projects hostet in /var/www, some are private files, some are my wife's, and I store them on my own server remotely.
Locally I need to be free, symlinks don't work for several reasons (imagine a software update removing and re-adding files in their physical location) a delete will just delete the symlink and recreate the file. etc.
On my linux machine this also has user issues, files are owned by users on my machine with permissions set. When I log in with my wife's account she must actually have her own access. It would be stupid to have one shared folder locally that with this Sparkleshare has to be split up into two folder. Especially as this is for large amounts of data.
Of course if adding a symlink in the Sparkleshare Folder would suffice, to sync the actual file, it would work for me (
storage@remoteserver:PORT/home/storage/myProject synced with : /home/triple5/Sparkleshare/myProject ->/home/triple5/projects/myProject
storage@remoteserver:PORT/home/storage/sharedlocally synced with: /home/triple5/Sparkleshare/sharedlocally ->/home/triple5/sharedfolder
storage@remoteserver:PORT/home/storage/sharedlocally synced with: /home/mywife/Sparkleshare/sharedlocally ->/home/triple5/sharedfolder
but of course follow symlinks is probably not an option here, so it should be like this:
storage@remoteserver:PORT/home/storage/myProject synced with: /home/triple5/projects/myProject (me can access)
storage@remoteserver:PORT/home/storage/sharedlocally synced with: /home/triple5/sharedfolder (me and my wife can access)
This feature is a must. how can I help implementing?
This would solve all my problems, in the same way ass triple5 is explaining, some files are /var/www some are /home/username/documents some are /home/username/school. I also feel it is a must, it might be wrong to have one advanced option, but in my opinion functionality before great-look. I only use this option once when i add new projects, so it doesn't bother me much that one time when i use the gui of Sparkleshare. Hope you will take it in consideration.
What about a right click context menu? Similar to the git extensions for windows
Then we could have the entire SparkleShare menu in the right click menu, which would make it context sensitive.
Some use cases:
1. Right click empty window > SparkleShare > Add Hosted Project. Adds the project to a new folder using the project name
2. Right click empty folder > SparkleShare > Add Hosted Project. Adds the project to that folder
3. Right click folder with contents > SparkleShare > Add Hosted Project. Notifies the user that hosted projects can only be added to empty directories
An alternative to 3 would be to include the folder contents in a working directory and somehow merge that with the remote repository.
I was imagining something like this
I'm just going to chime in and say that being able to have projects at arbitrary locations would be really nice. Symlinks work but are more annoying to set up then just cloning to the first place first time.
I also want to chime in to say that a different folder per repository is needed.