111–120 of 143 posts
OK, this is probably a very dumb question, but I'm trying tio understand the usecase. I put things that I want to sync with Dropbox in /Dropbox and take out things that I don't want to sync. Why would I want to leave things in /Dropbox that I don't want on Dropbox?
It's strange to me that Dropbox has thousands of employees, people have wanted this for a _long_ time, and yet this hasn't been built.
You'd think that with more engineering/PM/design talent the product would get better, and faster.
Anyone have any insight into why happens? I've never worked at a early stage startup but here are some hypotheses:
- Maybe this is a good thing. After a product is "done", adding more functionality makes it worse, not better.
- Maybe the company leadership's focus shifts from building a great product to scaling as fast as possible. And doing both at once isn't possible.
- Maybe the engineering division grows substantially, but the number of people actually working on the product doesn't change much. Instead the new engineers work on important, but auxiliary things, like dev tooling, security, infra, ops, etc
- Maybe developing features takes longer because there's more process: security/legal/ops needs to review it, several layers of management need to approve it, it needs to work in multiple countries, etc
- Maybe the urgency to keep improving your product disappears after you feel that you've made it
- Maybe it's more important to take longer to build stable, complete features instead of shipping as fast as possible
Earlier quoted context omitted.
Personally I prefer that build artifacts end up somewhere under my current working directory. That means if I want to clear everything out related to a project, it's easy to do so without interfering with anything else.
Yes, as frustrating as it is to need on occassion to rm -rf /node_modules and start again to fix things, at least that's an option.
The most requested feature, to allow a file or folder to be ignored by Dropbox sync without using selective sync is finally in beta. The community requested a .dropboxignore file but they chose another solution which I’m sure is reasonable for making the feature more user friendly to non-devs. This will be immensely helpful for node_modules or build target directories.
for those using google drive or onedrive, we have ignore rules which supports gitignore syntax -- https://help.insynchq.com/en/articles/3045421-ignore-rules note: i'm a co-founder
To clarify, Insync is a client used in place of Backup and Sync / Drive File Stream? Do you have a Linux CLI client? I have a headless Ubuntu server at home that I sync personal files on. Currently using Dropbox but in the process of switching to Google Drive (both a personal and business account) and it seems like there's no good CLI only client for Linux.
we are asking for feedback here -- https://forums.insynchq.com/t/feedback-wanted-insync-3-headl...
Genuine question, why do people here use Dropbox or box when Google drive is far superior?
Earlier quoted context omitted.
I put everything in Dropbox including all of my projects. In my experience it works pretty well even if node_modules can't be ignored now. Putting every projects in Dropbox with .git is the most awesome feature of Dropbox. With Dropbox's History and Time Machine feature, you will be almost never able to delete/overwrite your work permanently, even by intention.
Why not just use github, gitlab or other VCS? Personally, I enjoy using Dropbox for music projects (which VCS are not well suited for), but for code... (I apologize if I sound as if I'm telling you what you should be doing; I am really just trying to understand the motivation behind such a decision - but I fully understand that even if something seems bizzare to me, it's just my personal humble uninformed opinion).
Still not sure if it’s a good idea or not, but not being able to ignore node_modules was the real blocker for me before.
Earlier quoted context omitted.
Yes, as frustrating as it is to need on occassion to rm -rf /node_modules and start again to fix things, at least that's an option.
Of course it still would be an option if these were stored out of tree, but it means I need to know where that is. I also have the potential to affect other unrelated projects.
Dropbox//node_modules/
or similar?