Ask Slashdot: How Best To Synchronize Projects Between Shared Drive and PCs?

Koookiemonster writes "Our company has many projects, each one with a folder on a Samba drive (Z:\). Our problem is syncing only the programmers' current projects (~30 at any time) between Z:\ and their C:\Projects\-folder on five Windows 7 laptops. If we sync the whole Z:\-drive, our projects folders would be filled with too many subfolders, making it difficult to navigate. The folders contain OpenPCS projects (PLC) and related files (Word, Excel, PDF documents); a common project folder is 50 MB. Is there any easy to use, low-budget sync software with scripting, so that we could e.g. only sync folders that exist locally?" (Read more details, below, of what Koookiemonster is looking for.) "Many programs do support selective sync, but choosing what to sync is awkward; projects and who works on them change daily. It is important that subscribing to a project is as easy as copying it from Z:\ to C:\projects\. The Z:\-folder with all of our current and past projects is located on a desktop PC running Ubuntu Linux. It can share files e.g. via Samba or FTP. All PCs are on the same (W)LAN. Off-site backups of Z:\ are taken care of via rsync. The company has three programmers, who usually handle their own projects alone, but very often others need to add files to projects. Bigger projects need more programmers. Currently we use FreeFileSync with a custom piece of Javascript to make batch files that synchronize e.g. folders C:\projects\123_ProjectName\ and Z:\123_ProjectName\ if the local folder exists. However, that solution lacks versioning, real-time sync and deletion support. It only syncs when we press a button, and then older files are overwritten by newer files (two way sync; older files go to a "sync-deletions"-folder).

PS. Bonus points for solutions that allow renaming project folders without renaming them on all laptops."

Comments

BTsync?

[pete.zhut]

I don't know if this will do everything you need, but I have been using it at home to backup three machines to my NAS. Seems to work quite well.

stop trying, use git instead

[Anonymous Coward]

you are welcome

Re:stop trying, use git instead

[camperdave]

stop trying, use git instead

... or one of the many alternatives.

Re:stop trying, use git instead

[Anonymous Coward]

You'll have to excuse him, he comes from Windows Land :)

Re:stop trying, use git instead

[GameboyRMH]

Correct answer almost on the first post, nice work ("svn" would also have been acceptable.)

TFA is describing a horrible clusterfuck that must be replaced with proper revision control. You don't build on top of this, you KILL IT WITH FIRE!

Re:stop trying, use git instead

[tippe]

In that case, he should use Visual SourceSafe!

Bwahahahaha! Just kidding! Just kidding! I wouldn't wish VSS upon my worst enemy...

Re: stop trying, use git instead

[Anonymous Coward]

Agree, for my worst enemy I reserve clearcase

Re:stop trying, use git instead

[luis_a_espinal]

You'll have to excuse him, he comes from Windows Land :)

Meh, I know you are posting in jest, but honestly, I've seen people from Unix-land also having no clue about source control/revision control systems. Proficient software people (Unix, Windows or whatever) know how and when to use such a system. Everybody else, well, you get what the submitter is describing :/

Re:stop trying, use git instead

[Darinbob]

Or just about any source code control system (most allow binaries as well). I can't think of any that don't allow syncing just files that are wanted. Further, these systems are designed to safely share the files, not just "sync"; files can be locked and made exclusive, or conflicts between multiple authors resolved, etc. This is essentially technology that's 40 years old.

Re:stop trying, use git instead

[Darinbob]

That's truel However I definitely have seen the syndrome of people not acknowledging software not created by Microsoft, or asking for bizarre or counterproductive requirements (sharepoint). Most Unix users who don't understand this stuff at least tend to follow along with whatever the team uses or project manager suggests.

Re:stop trying, use git instead

[Bacon Bits]

I wouldn't use git. Git requires you to always clone the entire repository. That's fine if the repository is just source code and text files, but the more binary files you have the less attractive this can be.

I still favor svn over git myself, but it just suits my workflow better than git.

Re:stop trying, use git instead

[gnapster]

svn is appealing in this case because you can check out subdirectories of a repo without downloading the whole thing, which is more similar to his current organization.

Re:stop trying, use git instead

[achbed]

This. Git is great if you want to maintain a full set of everything on every system - every copy is a full backup. If you want to do selective work, then svn checkout of particular branches is the way to go.

Re:stop trying, use git instead

[Koookiemonster]

OP here. Of course we have heard of version control, git and the like.

It is important that subscribing to a project is as easy as copying it from Z:\ to C:\projects\.

Does git accomplish this? Our programmers are comfortable on the command line, but our installer and CEO are not. Which solution would use you use with your mother?

easy to use

Let's imagine your mother has received a PDF document in her email, and she has to add it to the repo. Would you really make her use git? Just making her email the file to you isn't a good solution in this case.

Re:stop trying, use git instead

[CQDX]

Don't put everything into one git repository. If you have large binaries, or large even large plain text files (like input data for testing), put those in a seperate repository so you only clone what you need.

Re:stop trying, use git instead

[Bovius]

Let's imagine your mother has received a PDF document in her email, and she has to add it to the repo. Would you really make her use git? Just making her email the file to you isn't a good solution in this case.

I would not make her use command line git, but I would make her use one of the many GUI clients available for git. If she can be trained to use whatever you're using now, she can be trained to use one of these.

I would be nice to her and spend some time hanging out with her after the training, of course. She's my mom. I would also expect her to need repeated training, but I would expect that of anyone who is not tech savvy.

Re:stop trying, use git instead

[Obfuscant]

Let's imagine your mother has received a PDF document in her email, and she has to add it to the repo.

If your programming staff have the computer skills of the stereotypical mother that you are using as your example, then your company is in much worse trouble than just not having a good source control system.

Re:stop trying, use git instead

[alexhs]

syndrome of people not acknowledging software not created by Microsoft

Why would anyone install some perfectly working third-party application on a pristine Microsoft system ?
I suggest Microsoft Windows Briefcase.

Re:stop trying, use git instead

[Gr8Apes]

You apparently don't have the slightest clue how git works, nor how to use it properly. I certainly am no git guru, but have no issues with using multiple git repos in projects, building sub-systems out of it, nor branching and merging, which it truly excels at. I wouldn't wish SVN on anyone that wants to use branching. It's about as brain-dead as it can get and still "function", barely. The only thing SVN has going for it is that it is almost atomic, whereas CVS, MKS, etc, absolutely aren't. ClearCase is a separate system that can be used, but requires a full time expert admin for anything more than basic code repos. At least it handles branching almost sensibly. Mercurial was in the running, but at the time git had (and still has) a larger user base with active improvements in various tools associated with it for my needs, thus I chose git.

Learn a tool before you wrongly despise it publicly. You are wrong on every count:

• You don't get a full copy of everything on every system if you don't want it. You can just check out a single branch.
• Every copy is not a full backup. See previous line item.
• Selective work is easier in git, you can clone the item(s) desired, branch locally, and merge when complete, pushing only if desired.

Lastly, you can essentially "checkin" every change for a full history of what you did on a local branch, revert, merge other branches, etc, with no effect on the main dev branch(es). And you can do all this without even being connected to a "main" server. Maintaining parallel branches with constant merges is cake compared to SVN and other central repo schemes. There really is no situation where I'd rather use SVN or anything like it that I can think of, when I have a choice.

Re:stop trying, use git instead

[alexgieg]

I've hear tons of good things about SourceTree, a freeware Git / Mercurial client originally for Mac but recently released for Windows. I know it's used by lots of non-technical folk for non-coding purposes (think designers managing Photoshop projects), so it might work for your scenario too. I haven't used it myself though so I can't comment from personal experience.

By the way, you could set things so that you'd have a different repository for each project, similar to your set of root folders, instead of a single repository covering everything. That'd keep things neatly separated as users would be able to branch only the specific projects they're working with rather than the whole thing. And since it all comes down to the original files/folders being copied up and down with the addition of a few hidden metadata files/folders, end users wouldn't really notice anything is added under the hood unless they have Explorer set to show hidden files, evidently.

Re:stop trying, use git instead

[CQDX]

I think you are looking for a project management solution, a package to manage your source code AND documents. For that you might want to look at something like Redmine, a project management tool that gives you a simple interface to a MySQL database for documents, bug tracking, a wiki, editable calendars, Gantt charts, etc. as well as a front end to Git, SVN, and Bazaar code repositories. See redmine.org. There's a public redmine server there that you let's explore how it works.

Re: stop trying, use git instead

[Anonymous Coward]

The GP has a point, just uses the wrong terminology. He's referring to sparse checkouts which git does not support.

Re:stop trying, use git instead

[ChatHuant]

However I definitely have seen the syndrome of people not acknowledging software not created by Microsoft

Yup, seen that. And I also saw the reverse: people going to insane lengths to refuse to use a Microsoft tool or system, despite it obviously being the best fit for their particular problem. There are quite a few such specimens (of both categories) on Slashdot, and, while the logic contortions can be funny at times, I'm annoyed to see how often misunderstood ideological purity trumps technical arguments.

Re:stop trying, use git instead

[WuphonsReach]

git is a rather poor choice for binaries due to the way it stores things. SVN is the better choice for binaries, especially for a situation where you want a central repository server.

But really, the answer is "nearly any centralized version control system" is a better choice then trying to rsync/unison stuff around. With the advantage that everyone *knows* they have the latest (by asking the server) and you get full revision history for everything.

Re:stop trying, use git instead

[WuphonsReach]

SVN (with TortoiseSVN) is the better choice.

Create one repository per project (or per client), with a sensible naming scheme for the SVN URLs. For instance, put your repositories under /var/svn or /srv/svn, and give them all a 'proj-XYZ' style name (or 'client-XYZ').

We store all of our projects in SVN as well. Most of the files that end up in there are Word documents, Excel spreadsheets, plus a bit of HTML, scripts, and other things. So we're dealing with less technical users as well.

SVN has "sparse directory" support where your initial checkout is only "file children". In order to bring down deeper directories, you use TortoiseSVN repo-browser and tell it to bring down directory XYZ/ABC/123 (and give it a depth). So your users don't need to bring everything down, they can focus on a particular folder inside the repository. And change their minds later.

Toss WebSVN into the loop and you can give your users read-only views of all of the repositories via a web browser. This serves well for times when they want file XYZ, but don't want to jump through doing a sparse "update-to-revision" or don't have a checkout of a particular project.

Re:stop trying, use git instead

[WuphonsReach]

Actually, as long as you insulated VSS from clients trying to update things over a flaky network connection, it wasn't that bad (and somewhat resilient).

The best approach was to put SourceOffSite in front of your VSS repository. Then force all clients to use the SOS client over the network instead of putting the VSS repository on a network share.

(We went from monthly issues with corruption to maybe once per year. Of course, SOS was not cheap, so once SVN matured we migrated away from VSS/SOS.)

Re:stop trying, use git instead

[CSMoran]

Seconded. I use a 65GB git repo across four machines (two of them virtual) to sync my entire work history on a daily basis. Occasional 200MB files in there, but mostly smaller stuff (source, binaries, PDFs, word documents, datafiles). Never had a problem so far. Admittedly, no branching, just keeping a few hundred thousand files in sync across four machines so that I don't have to worry where my files are when I go somewhere with my laptop only.

Re:stop trying, use git instead

[hendrikboom]

Try monotone. (http://www.monotone.ca/) It works on Windows too. You might need custom merge scripts to handle compressed files (such as word-processor files), though.

Sycing monotone between machines is easy. You use the sync command and everything is copied back and forth. Yes, it will distinguish the changed from the original version, and it will *not* copy the wrong way.

You don't need to merge before syncing. You don't have to sync all projects. But if you do, everything will automatically be backed up on your multiple machines.

One review of monotone (I forget where) said "It gets the user story right."

I use it to maintain projects in mulitplicate between my desktop machines and my laptop.

Re:stop trying, use git instead

[jhol13]

I heavily recommend distributed version control system (git, mercurial, darcs, ...). You'll regret few years later if you don't.

Re:stop trying, use git instead

[turbidostato]

" There really is no situation where I'd rather use SVN or anything like it that I can think of, when I have a choice."

So can git already manage binary blobs in any sensible manner?

Re:stop trying, use git instead

[jhol13]

There is UI's like TortoiseGit for Git. But I'd recommend to evaluate other DVCS's too like Mercurial (& TortoiseHg). They may fit your needs better. Don't waste your time evaluating too much, the all are perfectly fine. But do pick a *distributed* VCS instead of simple VCS. They are Just Better(tm).

Putting a PDF into git in a way does not make sense, but then it does not hurt either. Sooner or later you'll notice it saves your day and therefore did make a lot of sense. It makes much more sense than putting it into e.g. Sharepoint, although your intuition may suggest otherwise. Really.

Re:stop trying, use git instead

[MikeBabcock]

git, rsync, etc. are all excellent options.

Why on earth is anyone sync'ing server folders in 2013 anymore?

Re:stop trying, use git instead

[philip.paradis]

Perhaps you haven't spent enough time with git. I've used it for years to manage data stores with content ranging from rST documentation bound for rendering to a very widely read open source "howto" site (with constant edits and merges from a small team of technical writers) to large scale development projects. In fact, I use it for all my file and source control to this day, and my employer's dev group uses it as well to manage a rather extensive codebase responsible for driving an enterprise cloud hosting provider's operations.

If you've had problems with git, you should be aware that there's a huge community out there ready and willing to assist you with whatever workflow you've decided to adopt. One of the nicer things about git is the fact that you can use it in a very SVN-like manner if you like, or you can make as many branches as you want and manage things in a very distributed manner. Again, I suspect your primary problem is lack of experience.

Re:stop trying, use git instead

[inasity_rules]

May I suggest you consider re-reading GGP's post. Your reading comprehension of it is broken,

Re:stop trying, use git instead

[inasity_rules]

I have a similar problem to OP. My intended solution was mercurial, but I have one huge issue with it - I am the "linux guy" at this company, and nobody else is interested in logging in to create repositories from the command line. I am not a full time admin here (we all share the load), but most of the linux admin falls to me, and i do not have time to create lots of repositories. Is there a package that will allow us to create repositories for new jobs from a browser? I am not interested in writing a custom tool for this - I simply don't have the time.

Re:stop trying, use git instead

[mlk]

Is that checkout or clone?

Re:stop trying, use git instead

[mlk]

I think SVN supports web dev and can be mounted as a drive in windows. But I'm not sure how well it handles commit conflicts in this form.

Re:stop trying, use git instead

[Gr8Apes]

Nope, I've just 50+ separate artifacts with roughly 2 million LOCs building a total of 5 deliverable components for one 3 year project. A 1 million LOC project with 3 components on another 1 year project. A 20 component distributed system with unknown LOCs across more than 10 source repos for another 1 year project.

Nope, I bow to your anonymity.

Re:stop trying, use git instead

[Gr8Apes]

SVN is better?

Re: stop trying, use git instead

[Gr8Apes]

You mean like this?

Re:stop trying, use git instead

[Slashdot Parent]

svn is appealing in this case because you can check out subdirectories of a repo without downloading the whole thing, which is more similar to his current organization.

Actually, you can now check out subtrees of a git repo. It's called "sparse checkouts", if you want to do further reading.

But if you find yourself wanting to do this, you should consider that you might be using git contrary to its design.

Re:stop trying, use git instead

[gnapster]

Thanks a lot! Last time I had looked for such a feature in git, it didn't exist. I do understand that the git philosophy is to make many discrete repositories rather than one repo with many projects organized in subdirectories. It just seemed that sparse checkouts were a closer analogue to OP's current situation, which might mean a lower learning curve. Although as I think about it, making several sparse checkouts for different projects is nigh-indistiguishable from cloning several discrete repositories, from the user's perspective.

Re: stop trying, use git instead

[gnapster]

Well, that's most of the way there but it still requires downloading the whole repository first, and then some configuration, and you have additional unnecessary directory structure.

However, upon reflection, I'll agree that it is probably better for the OP to go all the way and make a repo for each project, which is the standard practice with git. But I'm not convinced that sparse checkouts, as described in your link, is a drop-in replacement for svn.

Re:stop trying, use git instead

[Obfuscant]

May I suggest you consider re-reading GGP's post. Your reading comprehension of it is broken,

I don't know who "GGP" is, but I read Koookiemonster's post. His argument against using git is based on a hypothetical stereotypical computer illiterate mother. In response to a claim that it was easy, he asked about the poster's mother.

That implies that the people who would be using git in KM's company have the computer skills of a mother. Since the programmers would be the ones using it, that doesn't bode well for their skills.

Re: stop trying, use git instead

[inasity_rules]

Again, go back and read it. He quite clearly states that the issue here is with the CEO and installer (wireman perhaps), not the programmers. And he has a good point. I work in a similar setup, and sometimes non technical people need easy access to what I do (the wireman needs a drawing modified, the documentation may be required to be modified when I am not in the office, etc). While any engineer could perform this task, he is correct in stating that if we need to pull an engineer to do these tasks, the solution is not sufficient. Just because everyone where you work is a programmer by proffession, does not imply every shop runs like that. And yes, we could hire someone to manage the whole thing, but the original question is what software can solve the problem without having either someone useful sitting being useless most of the time as an admin, or a solution that is not accessible to a non programmer.

Re: stop trying, use git instead

[Gr8Apes]

My comment would probably be that sparse checkouts aren't smart to begin with, and why would you do them? SVN sucks in so many ways, perhaps the problem isn't with git and how it works, but with the perceptions of people who've compromised efficiency for familiarity, much like many people got used to MS Windows XP and find all other systems "inferior" when it's really a familiarity question. If you've only learned to hammer a screw, odds are you'll find a screwdriver inefficient and bad.

Re:stop trying, use git instead

[turbidostato]

Yes.

Re:stop trying, use git instead

[WuphonsReach]

serverfault answer

Re:stop trying, use git instead

[inasity_rules]

I will look into that. Thanks.

Re:stop trying, use git instead

[Gr8Apes]

No.

Re: stop trying, use git instead

[gnapster]

I guess my first line above could have been paraphrased like this:

You mean like this?--

Not really, because that solution is a poor shadow of svn's sparse checkouts.

Your point, however, stands: it is clear that – whatever sparse checkout features git may have – git's 'sparse checkout' abilities were added because of popular demand, not because sparse checkouts are a good idea. You obviously view them as a crutch, and I have no argument; I even believe I can see where you're coming from. If I invested the time necessary to master git, and spent time collaborating with others and sharing my code, I would probably reach the same conclusions.

Re:stop trying, use git instead

[masterjames]

http://labs.bittorrent.com/experiments/sync.html bittorrent sync is a really cool tool that i use for this. its free and the more machines in the group to sync the faster it will sync.

GIT?

[Anonymous Coward]

What about using GIT? (or other similar versioning tools)

Re:GIT?

[chuckinator]

This works great with only one caveat: most office documents are binary files (or are treated like binary files by the SCM), so you'll need to put a process in place to lock the file in question prior to editing to prevent people stomping over others' changes to them.

Re:GIT?

[timeOday]

Maybe, maybe not. MS Word has its own functionality to merge changes from different versions, so you might not want to lock it down. The big problem with locks is people forgetting to check things back in and locking everybody out.

Re:GIT?

[camperdave]

...you'll need to put a process in place to lock the file in question prior to editing to prevent people stomping over others' changes to them.

That's one of the fundamental functions of version control software. No?

Re:GIT?

[Nemesisghost]

That's why you pair GIT with GITLab(a private/local version of GIT Hub). Or if you want to purchase something, go with RTC or JIRA. RTC & JIRA have the added advantage of issue/bug tracking, but all offer you the capabilities of adding a SharePoint/Wiki like site to your revision tracking.

Re:GIT?

[Atzanteol]

No. Only those that require a "checkout; modify; check in" work pattern. Git, SVN and others follow a "modify, merge, commit" pattern which requires no locking. Though SVN can be configured to "require" (more like "request") locking on binary files which would help.

Re:GIT?

[luis_a_espinal]

This works great with only one caveat: most office documents are binary files (or are treated like binary files by the SCM), so you'll need to put a process in place to lock the file in question prior to editing to prevent people stomping over others' changes to them.

That's typically not needed. MS Office products, for instance, have built-in diff review-n-merge capabilities. And even without such a capability, a src-controlled binary is simply that, a coarse-grained resource. Whoever commits the last is the one whose changes prevail. This is what is done with SharePoint anyways or TeamSite anyways. No need for locking.

Re:GIT?

[Darinbob]

This is also one reason to use something other than binary only or proprietary format for documentation, or to split the documentation up into many small files. Text or basic HTML works great. Wikis or wiki-like servers are also good (though you may end up in a fight against the MS faction in IT that insists you use Sharepoint instead, at which point you're better off changing companies).

The problem with things like docx is that while it is textual it is not necessarily structured uniformly so that minor changes to a doc could require huge changes to be merged, or even slight variants in Word versions result in large document differences (docx is essentially a dump of internal state). Maybe that's fine for some people but it can result in a very large increase in required storage space.

Re:GIT?

[achbed]

Mbvious Microsoft questioner is obvious (syncing "C:" and "Z:"?). Microsoft shill would have recommended Azure and VS2013 Cloud Services for source and revision control. Which I would never, ever do - give all my source code to another firm? Hells no. I hesitate to put anything in github for the same reason.

Re:GIT?

[WuphonsReach]

TortoiseSVN is smart enough with MSWord documents to call Word's diff engine.

Still not as smart as keeping your documentation in something more portable, like lex/tex or XHTML.

Re:GIT?

[chuckinator]

You still need to lock your files before you bang hard on the awesome Office built in functionality. It doesn't change the fact that you diff and merge your changes with Bob from accounting while he's working on the same thing, you check yours in, then he checks his in, and magically your changes disappeared. I wasn't arguing about the value of the internal revision tracking of the tools in question; your changes will still get blown away the first time you work on a document at the same time with 2-5 other people and it turns into swiss cheese. They worked on their copy that they checked out at 9am just like you did when Alice mailed all of you that check just pushed a new revision and needs your review and commentary. In fact, the built in tools of applications you choose to work with make the problem worse because of people being over confident about their pet tools.

Re:GIT?

[jrumney]

That's [locking] one of the fundamental functions of version control software. No?

Not since 1986, when CVS was introduced to the world. For the frequency that real conflicts happen in the real world merging ends up being less inconvenient than locking, as the latter also gets in the way of work that does not really conflict.

Re:GIT?

[jedwidz]

Yes, but my experience was that merge conflicts in Word docs were frequent and painful to resolve. So we introduced a 'lock before edit' convention for Word docs (and same could be said for any file not edited as text).

Merge conflicts in tables are bad enough, and that's fairly basic functionality. Good luck with merging changes to embedded media.

OwnCloud is pretty good

[charnov]

https://owncloud.org/

Keep the masters in a private cloud and sync to it from your PCs. Git and other multi-user SVN is an idea, too. Also, SharePoint is excellent (but lots of overhead).

Re:OwnCloud is pretty good

[Amouth]

I'd like to chime in on ownCloud. It works but it also doesn't

Owncloud fails in a large multi user environment over low speed connections, and with office files if the users are working in the same folder that syncs. We tried it, and for single in a folder it worked great, once we added others (especially with low speed or low quality connections, aka traveling users) it failed miserably. We had many many many conflicts for no reason. many many 0 byte files do to cross sync issues.

We ended up canning it because managing it and cleanup became too much of an issue. We now use DropBox (i know not open source and you pay) but the reality is it just works. And it has the selective sync they are looking for.

Re:OwnCloud is pretty good

[Idimmu Xul]

ive been playing with owncloud for the last week, it's awful, it loves just deleting all my files or corrupting them :(

Re:OwnCloud is pretty good

[nschubach]

I've found Bittorrent Sync great for selective syncing... You select a folder to sync and it gives you a hash that you can give to someone else who just needs that hash and they can specify any folder for those files. If you have a project wiki or something you can just put the hash alongside the project name and anyone that wants that synchronized folder can put in that hash. It does LAN syncing so it doesn't always have to hit the web, you could setup a server assign each project to a sync target and share those keys.

Re:OwnCloud is pretty good

[transporter_ii]

We ditched OwnCloud for GoodSync. OwnCloud in theory works OK. However, if someone with a laptop is away from the Internet, it is real bad about losing all the client settings and just quits syncing. Also, in the right circumstances, it can generate a huge amount of files by versioning during collisions.

GoodSync is not perfect, either, but it is far superior to OwnCloud. Is it free? No. Work better? Yes.

In theory, GoodSync has support. I was not thrilled with it. We kind of got cross and they thought I was rude, and I think they aren't that good at support.

Pros: They have a server version that runs on Linux.

Cons: The Windows Server version costs a fortune. Spotty support for the Linux version. Support for the Linux version is basically, "Linux is hard," don't use it if you don't know what you are doing."

Re:OwnCloud is pretty good

[Amouth]

I got in on the Alpha of that, but didn't have time to fully review it. I will have to go back and look at it.

Thanks,

Re:OwnCloud is pretty good

[siDDis]

Stay away from Owncloud....really, those guys don't even know that all modern filesystems have an API for watching changes in your filesystem. And syncing works on file level instead of block level.

Re:OwnCloud is pretty good

[butonic]

Again, try the new version 1.4. As discussed in https://github.com/owncloud/mirall/issues/29 inotify on linux does not guarantee that the sync client will get notified of file changes under all circumstances, so we do need to poll. Any constructive hints are welcome.

Re:OwnCloud is pretty good

[butonic]

Which client did yo use? We just released 1.4 that solves a TON of problems. Would like to hear about your problems being solved an especially those still persisting.

Re:OwnCloud is pretty good

[BitZtream]

Citation needed.

All I've seen in your issue tracker is a half attempt at an excuse, not an actual reason. And that only applies to Linux, (and again, I've yet to see an example of the behavior you're claiming).

If you find such behavior, that would be a bug you should report and log in your issue tracker so users know they can upgrade to a patched kernel without the issue.

Windows most certainly will tell you EVERY SINGLE CHANGED FILE individually, without missing a one.

I've not had personal experience with OSX, but I'm fairly certain that apps I use do not scan the 40k files in my watched directory looking for changes, I'd notice that I'd think.

Re:OwnCloud is pretty good

[KlausKoe]

I tried OwnCloud several times. Last time was about 3 month ago. I have a dropbox account with several eclipse workspaces and want to move to owncloud. So there are >20K files and almost 2GB. It seems like the sync client can't handle that amount of files. Even after 5h only 120MB were synced. I think I also found several post about bad performance and it might even be a general issue in the way the sync is done. If you only have few files it might be OK but with all the additional eclipse/java files it's not suitable add all.

Revision Control?

[Anonymous Coward]

This sounds like the ramblings of someone who has never heard of revision control.

Re:Revision Control?

[camperdave]

Maybe he's one of the Ten Thousand

Re:Revision Control?

[BitZtream]

Heh, thats a good one. I'm typically an ass about that sort of thing, I think the xkcd approach is far better now that I actually think about the process.

A Small Voice In the Wilderness Calls Out

[the eric conspiracy]

USE VERSION CONTROL!!!!

Git
Mercurial
Perforce
Subversion
Vesta
CVS
ClearCase
VSS
StarTeam

The choices are legion. What you are doing is not a choice.

Pick a version control system and your life will be much easier (after the learning curve).

Re:A Small Voice In the Wilderness Calls Out

[Dieppe]

USE VERSION CONTROL!!!!

Git Mercurial Perforce Subversion Vesta CVS ClearCase VSS StarTeam

The choices are legion. What you are doing is not a choice.

Pick a version control system and your life will be much easier (after the learning curve).

I think this story can be closed with this post right here. Version Control, end of story. P

Re:A Small Voice In the Wilderness Calls Out

[Anonymous Coward]

Why close? We can now start the entertaining flamewars about which version control software is the only reasonable one! ;-)

Re:A Small Voice In the Wilderness Calls Out

[luis_a_espinal]

Any of those but ClearCase. What an awful tool.

It's not great (not my first choice), but it is not that awful either. I like the concept of a vob and the powerful access control models that come with it. It's just the idiotic complexity of attributes and objects in ClearCase that uglifies it.

Re:A Small Voice In the Wilderness Calls Out

[Anonymous Coward]

We're still old school CVS and SVN users but are starting to use Git. Many of the devs use it for other projects and it works quite well for our workforce (8 devs in four timezones).

Re:A Small Voice In the Wilderness Calls Out

[the eric conspiracy]

I've used many of the above. Here are some comments (the first four are free):

1. Git - really capable tool, with opaque command model. Maybe not for newbs. Managers hate using it (one reason to like it). Has good cloud support with GitHub.

2. Mercurial - pretty easy to use. Great if your projects don't have large binary files. It's a good introductory decentralized repo tool.

3. Subversion - pretty good if you want a centralized repo.

4. CVS - your father's version control system. Still way better than not having version control.

5. ClearCase - good in the hands of a ClearCase specialist. Would not be my choice for a small team of version control newbs.

6. VSS - My experiences with it were not good. I hear it's improved. I'd look at it ONLY if I was in a Microsoft only shop.

Re:A Small Voice In the Wilderness Calls Out

[Richy_T]

It's time someone constructed a version-control file system. I mainly use subversion and it can be a real pain when you used mv instead of svn mv. (And other related commands). These things should be transparent (not that that's an indictment of Subversion).

Re:A Small Voice In the Wilderness Calls Out

[Richy_T]

Keeping two copies of everything is also needless.

Re:A Small Voice In the Wilderness Calls Out

[WuphonsReach]

Maybe btrfs... can't remember if that is in the spec.

You can also do fun things with the various VCS such as mounting them as file systems (svnfs, gitfs, etc.).

Re:A Small Voice In the Wilderness Calls Out

[QRDeNameland]

6. VSS - My experiences with it were not good. I hear it's improved. I'd look at it ONLY if I was in a Microsoft only shop.

VSS is a deprecated tool at this point, last updated in 2005, and only having extended support from Microsoft at this time. Team Foundation Server is Microsoft's current source control offering.

Re:A Small Voice In the Wilderness Calls Out

[jrumney]

It's time someone constructed a version-control file system.

That's basically what Clearcase is. And why it needs a Clearcase specialist to administer it.

Re:A Small Voice In the Wilderness Calls Out

[SIGBUS]

It's time someone constructed a version-control file system.

ZFS could be used in such a manner via snapshots and/or clones. On the other hand, you'd need to manually document changes, and there isn't any nice wrapper for network use.

Git

[Anonymous Coward]

Git is all you need

Not sure if he is looking for version control

[simoncpu was here]

Not sure if he is trolling, or if he has deeper issues that can't be solved with version control systems like git or hg (or even good 'ol CVS!).

Re:Not sure if he is looking for version control

[Darinbob]

I wonder how a company even gets into this situation. Granted, I don't think many schools teach the fundamentals of how to actually manage a project but I think even in the greenest of startups there should be at least ONE person who's held a real job before and has seen this. Nothing here is new. SCCS was started in 1972. Having multiple programmers on a project has existed since computers were invented.

My guess is that you get some clueless business oriented guy making a startup ("I'll get rich, my idea is Brilliant!") who then hires the cheapest/dumbest employees he can (he has no money to pay them but lots of worthless equity). So idiot in charge of the company and the actual workers are straight out of school and have never seen an actual professional programming team. The whole thing is probably run like a college programming class assignment.

The Joel Test

[Anonymous Coward]

Maybe you should give your team the Joel Test. I think you want source code control. Maybe subversion or git?

Re:The Joel Test

[K. S. Kyosuke]

Writing code in a compiled language is one of the last things that still can't be done instantly on a garden variety home computer.

Why should one listen to a guy who's apparently never heard of incremental compilers?

Subsetting a repository of files

[Empiric]

Sounds exactly like what an RCS like Subversion is good for.

Each user pulls down the directories relevant to him/her from the overall repository, updates at will from the central source, and pushes up changes at will with a couple of mouse clicks.

TortoiseSVN will even give you handy little icons on your local folders in Explorer to tell you if what you have in your local directory isn't synced with the central server, and it's two clicks to make that happen. I actually think you don't want to "force synchronization" on an ongoing basis, seems like a great way to overwrite a lot of your developers' (and others') ongoing work.

Re:Subsetting a repository of files

[Empiric]

Hey, I get enough attempts at that here just from being theist. ;)

Re:Subsetting a repository of files

[scrib]

Yours is the answer I wanted to write and is the solution I've used for just such situations. However, it violates one of the first ridiculous requirements: "It is important that subscribing to a project is as easy as copying it from Z:\ to C:\projects\."

Koookie, that may be an easy way to copy files, but it is a miserably difficult way to manage projects - even for developers. SVN takes a little time to set up and understand and requires maybe a day's worth of training for any developer who hasn't used source control before (eg some college kids). As you can tell from the chorus, version control is worth it. It is absolutely crazy to try to do what you are describing without it. Give up the absurd "easy as dragging and dropping" requirement and use the tools of the trade.

Re:Subsetting a repository of files

[djmurdoch]

If the admin keeps Subversion working copies of each project in Z:\, then developers can indeed just copy the top level directory of each project from Z to C and get their own working copy.

Re:Subsetting a repository of files

[Koookiemonster]

Thanks for your answer. I will look into TortoiseSVN. As I wrote above, of course we do know about git and the like, but the problem has been usability. We are not familiar with easy to use GUI clients. The solution should be something you could make your mother use (because of our CEO and installer, not the programmers).

Re:Subsetting a repository of files

[Zontar The Mindless]

We are not familiar with easy to use GUI clients. The solution should be something you could make your mother use (because of our CEO and installer, not the programmers).

No RCS on the planet can cure a CEO who insists on micro-managing something she obviously knows nothing about.

Get. Out. Now.

Run, do not walk.

Re:Subsetting a repository of files

[WuphonsReach]

Our approach (we use SVN) is to create working copies for every single client under a C:\Clients\xyz scheme. Where 'xyz' is the 3-letter codename for each client.

Each of those working copies is created with a script (stored in a 'svn-scripts' repository) that does a "file children only" checkout. The svn command for that is "svn checkout --depth files URL targetdir".

Because we only bring down immediate file children in the root of the repository, it doesn't take up much space. And bringing down a particular project folder from within the repository is made much easier.

1. Right click within the working copy -> TortoiseSVN -> Repo Browser
2. Find what you want, r-click, and "Update to Revision".
3. Make the depth "working copy" to bring everything from that point and below down to your working copy.

After which you work with the working copy as normal (commit, update, etc.). When you're done with the project, you can erase it off your hard drive with another "update to revision", this time picking "exclude".

(Yes, it's a little obtuse how to work with sparse working copies and I wish they'd improve it. But it does work without too much effort.)

Why not use source control?

[gmezero]

We used to use ViceVersa Pro to sync our team but eventually moved over to Plastic SCM which has been friggin' awesome. It not only supports code, but also art assets. Plus it has the best support for branching. One team can be working on a branch specific to one project, while another works on a second branch while the main trunk stays clean and build-able. You can even have developers run their own local repository on their desktop/laptop and have them replicate/merge either on a schedule or when they connect to the LAN (if they work offsite alot).

You only bring stuff back to the main trunk when you're ready to merge a branch back in. You can even merge branches separate from the trunk. We check everything into it, code, art, and our Doxygen output. It's been a time save on orders of magnitude.

Not trying to be a sales pitch, but you should check it out.

Re:Version control is for pussies

[steak]

I like your idea, but it needs some pizzazz. I think if you make a thousand chimps on teletypes write the scripts you'll get the effect you want.

Don't try syncing files

[MobyDisk]

Syncing files like this is a mess. Perhaps you should look beyond share drives. You are trying to solve the technical problem, but if you step back you might see a business problem. Consider 3 alternative approaches:
1) Keep the files on the share drive and do not mirror them locally.
2) Use a source control system (Ex: GIT, TFS, Subversion)
3) Use a groupware / content management system / document management system. ( Ex: Sharepoint, Confluence, QDMS, Lotus Notes, Microsoft Exchange, Drupal, SAP, Groupwise)

Knowing the right terms helps find the software you need. Here are some links to Wikipedia which has the right terms, and some lists of software:
http://en.wikipedia.org/wiki/Content_Management_Systems
http://en.wikipedia.org/wiki/Document_management
http://en.wikipedia.org/wiki/List_of_collaborative_software#Comparison_of_notable_software

Re:Wow, Windows is really still that bad?

[Anonymous Coward]

Windows Sync Center http://windows.microsoft.com/en-us/windows-vista/sync-center-frequently-asked-questions/ is a functioning offline file sync built into the OS since Vista with other capabilities coming in as early as Windows 95/NT4. Good to know that you just don't care and can't be bothered to add a suggestion, though.

Source control (best) or Offline Files (okay)

[FreelanceWizard]

You have programmers. You have multiple projects. They might be working offline. For this, you really need a Distributed Source Control system such as git or mercurial. I personally recommend mercurial as it's got good Windows tools (TortoiseHg and HgScc for Visual Studio integration). You can put your "pure" repository on your share, then have the programmers push to it -- or, better yet, have an "incoming" for each project to which anyone can push, then a "pure" to which only project leads have write access and into which they can push approved versions.

If, for some reason, you simply can't run source control, Windows offers Offline Files functionality that can sync individual folders if you set them up correctly. What this means is that you need to ditch this "shared drive" concept and set up your file shares correctly -- by which I mean having multiple shares, one for each project. Users then connect to the share in question and choose to make it offline, or you create drive maps and enforce offline files using group policy.

My suggestion: hire programmers

[sideslash]

If you hire experienced, competent programmers, they will be able to solve this issue for you. First they will suggest using version control (it seems frighteningly likely from your writeup that you're not currently using it). Probably git, but there are other good ones.

At that point the problem will become redefined. What you want is a script that:
- Iterates through the local working directory.
- Finds project folders that are NOT being worked on, and are also currently clean (no uncommitted files), and deletes them.
- Finds projects that need to be there and aren't, and git-clones them.

A competent programmer can write a script like this. And beyond that, for many reasons it should be the programmer's responsibility to commit stuff day to day. Also you may want to switch to a text file documentation format to eliminate merge conflicts in binary files (Word, Excel). Maybe you wanted a different answer, but I'd like to think that you're on the wrong site for that.

Re:Wow, Windows is really still that bad?

[mrbene]

Robocopy ( http://technet.microsoft.com/en-us/library/cc733145.aspx ) is included in all desktop versions of Windows (so, not RT or Phone). Extensive copying/moving/mirroring options, CLI-only. Great for integrating into scheduled scripts.

I'd still agree with other poster here, and recommend git over Robocopy to the OP. However, Windows does have a robust tool for syncing files between multiple computers built in.

In fact, Robocopy has been available since Windows NT 4.0.

It's sad

[msobkow]

It's sad to see an entire team of supposedly "professional" developers which have never heard of version control.

You can't even blame it on the Windows environment -- MSVS supports hooks for several version control systems either natively or through plugins/addons.

This whole story just reeks of some manager saying "We can't afford to set that up -- it would take too much time" any time someone has suggested it.

Because I flat out refuse to believe the entire team doesn't know any better.

Re:It's sad

[Freshly Exhumed]

As soon as I saw all those drive letters in the guy's summary I just knew where this was going... very sad indeed when coders don't have a clue about the tools that obviously suit them best.

Re:It's sad

[jon3k]

Me thinks no one asked the programmers. Some IT helpdesk guy is trying to solve it.

Re:It's sad

[sproketboy]

I do if they're microsofties. Total idiots - the lot of 'em.

Re:It's sad

[Darinbob]

I was at one company where most programmers were independent. It was sort of an odd business model that derived from the mainframe world; an author would write an application, write the docs, package it up, maintain it, and also collect a declining percentage of royalties. If the program was successful you could hire a developer to assist.

So my boss and I were the only people working on 2 programs. My boss learned with a "Learn C in 20 Days" book and previously had only done mainframe assembler and service. The program was on several varieties of Unix, MVS, and on Windows NT. So I started writing a simple Make script. My boss thought it was a waste of time but said as long as I got my work done it was ok. Seriously, his build system was a shell alias that was "doall='cc p1.c; cc p2.c; cc p3.c'" and so forth. Later I used RCS and he similarly thought it was pointless.

One day he comes into my office and sees me just browsing the web. He says I was supposed to be building the code for all the systems. I said that I was, and pointed to the terminal that was using running Make on each machine in sequence. He was very surprised that it was possible to automate it all and never complained again when I was working on using build tools.

So ya, these environments do sometimes come into existence. No real team in place at all. We didn't even have QA until it all blew up once with a customer. The groups really only cooperated to share machines and to make sure the programs interoperated. I came sort of at a transition though when everyone realized the old model wasn't working well and that the company was big enough that something smarter had to be done.

Re:It's sad

[WuphonsReach]

Because I flat out refuse to believe the entire team doesn't know any better.

It's way more common then you'd think. I worked for a company back in 2000, with close to 20 developers. Not a single one of them knew how to do version control. Instead, they all resorted to making copies of files, tacking on dates or times or just numbers, and relying on the backup tapes if they had to undo a particular change. It was hellish and you'd hear at least one conversation per week where they were trying to figure out who had the latest version of XYZ.

I rolled out VSS (hey, it was 2000, our choices were limited) with SourceOffSite for the remote workers. If I did it today, it would be either Hg, git or svn.

Very few schools back in the 90s or early part of the decade taught VCS concepts or forced students to use them. This is slowly changing with the advent of things like 'github' which has a big mindshare and introduces people to the concept of VCS.

Re:It's sad

[QRDeNameland]

Yep. In a former job at a very large financial services firm, I worked on their source control/build/packaging/deployment systems, and I was stunned by the number of developers who not only resisted using source control, but actually would not even acknowledge the value of it. One time, I raised gasps in a meeting of several dozen devs by making the statement "If you have a problem using source control, you have no business being a professional software developer." Yes, that was a controversial statement in a room full of highly-paid developers. In fact, now that I recall it, the company standard source control tool was PVCS as VSS was too flaky to handle the 300+ projects we managed, yet we had to implement VSS-PVCS import tools because the devs insisted that it was too much trouble to have to use a command window or separate GUI tools to do their checkouts/commits when VSS was integrated into Visual Studio.

So as much as a sane person might think that this would be obvious to a group of developers, it really depends on the developers.

SFFS

[zzsmirkzz]

If you don't want to do Version Control as others have suggested then I recommend Super Flexible File Synchronizer. It is a great product with lots of options in regards to what does and does not get sync'd. It is inexpensive to boot. http://www.superflexible.com/ftp.htm

If you can't use version control...

[neminem]

I suggest finding the person who says you can't use version control, and locking him in a room until he either changes his mind or ceases to be a problem. Then, use version control.

rsnapshot, rsync.

[Janek Kozicki]

http://www.rsnapshot.org/howto/

Well, actually probably rsync will be sufficient for your needs. And rsnapshot is probably a little more than your needs. I suppose that only thing you need to configure is a rsync server on windows, a nice writeup you will find here: http://www.stillnetstudios.com/snapshot-backups-howto/

I recently used this to configure my wife's windows PC, so that it will work with rsnapshot, and backup all her projects. After configuring rsync server on windows, the rsync operation works seamlessly. Whether you will use just rsync, or complement it with rsnapshot is up to you.

What are your programmers doing?

[damn_registrars]

You said you have programmers working on these projects. They probably each have their own preferred way to do this, why not ask them? If they can't come to a consensus, you could have them write their own solution.

Re:What are your programmers doing?

[Bengie]

If they can't come to a consensus, you could have them write their own solution.

If they couldn't do the first part, then they're probably not smart enough to do the alternative.

TortoiseSVN

[bob.lansdorp]

You are welcome :)

Re:Wow, Windows is really still that bad?

[luis_a_espinal]

Having no need for Windows, I really don't keep up with its capabilities. But, really, this is the year 2013 --- Windows is still that pathetic, that basic tasks like syncing files between multiple computers take special software that doesn't just come with the OS? Why is anyone still using that crap? Are corporations really so utterly incompetent on IT issues that they'd put up with shit like this because they don't know any better?

Dude, even on Linux, you need special software to synch files (rsync, git, whatever.) Since file synching is an app-specific functionality, this is not a OS problem. This is an operator problem, and I've seen Linux/Unix sysadmins doing the same kind of crap job as the one described in the original question/article/whatever.

This is a solved problem on both Windows or Linux/Unix. But incompetent IT staff exists on both domains. You can't defensively program against stupid (nor should you.)

Distributed source control.

[stewsters]

Use Git.

An analogy.

[pclminion]

"I'm a contractor. I have a team of carpenters who are tasked with building a house. It seems this is going to require the driving of a large number of nails. My team of carpenters would like to know what sort of tool or mechanism would work best to drive these nails. Right now, we have one guy who holds the nail while another guy hits it with his thermos. This does eventually drive in the nail, but 90% of the time the nail bends, and it's denting our thermoses. I wonder if there exists some genius, super-carpenter bad-ass out there who might be able to suggest a better way."

Re:An analogy.

[vux984]

I'd been drinking coffee, I'd be wearing coffee.
Thanks for this absolutely perfect post.

Re:An analogy.

[CodeBuster]

I'd been drinking coffee

From your dented thermos?

Re:An analogy.

[ax_42]

+1 for the followup

git-annex

[Horus107]

I second git. git scales badly with large files. If this is a problem, you could have a look at git-annex http://git-annex.branchable.com/ The concept needs some time to grasp, but it's really powerfull.

DO NOT USE GIT! Or you will be sorry.

[Kaz Kylheku]

Git is absolutely not a good first version control system for people who are clueless about version control. (Such as, evidently, your developers).

Git requires prior experience with at least two simpler version control systems. In git, you often run into scenarios that require you to understand its complicated repository representation so that you can choose the best steps to unravel them, based on understanding the ramifications of each approach.

The implementation of git is not hidden from the user behind a robust set of "no brainer" use cases.

The decentralized model alone will confuse the heck out of workers with no prior version control experience.

Use a system that has a centralized server from which working copies are checked out, like Subversion.

Re:DO NOT USE GIT! Or you will be sorry.

[badzilla]

When it comes to coding I am not what you call professional; I have always manually saved everything with file extensions like .works_except_for_that_bit or .saved_this_copy_before_changing_FooModule

Finally I thought I should try to get with version control but I could not even use Subversion. What a nightmare. All my code kept disappearing, I lost things, stuff I thought had vanished so I did it again then the original came back. Also you have to learn entirely new concepts what the hell does checking out mean. I am sure nothing wrong with the software but when you need to get some code finished who has time to climb some other learning curve.

recommendations

[hypergreatthing]

SVN or Git for code repository. Easy to set up, lots of windows and linux tools, command line based even if you want that.

However for documentation, i recommend confluence, or the many free wiki based collaborative solutions. This allows people to post on a wikipedia like site their documents. They become automatically searchable, people can collaborate in the documentation with version control built in. Confluence allows you to drag and drop ppt, import and export word documents, drop excel files in there or anything else it recognizes. The idea of single user word documents and passing around outdated versions is old and retarded.

There is also Synkron

[nashv]

The obvious "Use Version control/Git" is actually and improvement of your methods.
Here is an actual to the point answer to your question about software. A requirement of real time-sync was mention.

There is Synkron (has a scheduler) , OneSync (has real time sync), and Unison (uses rsync).

All are open source and free. Have fun.

Sparkleshare, git, and git-annex

[caitriona81]

Sparkleshare (http://sparkleshare.org/) is a "transparent" front end for Git which turns it into a simple file sharing tool. This would probably be appropriate for most of the actual "file sharing" applications the OP mentions (gaining many of the advantages of Git while keeping the complexity hidden until its needed), while obviously any source code fprojects should find their way into some kind of version control repository, probably Git as well, with TortoiseGit (http://code.google.com/p/tortoisegit/) being a fairly compelling solution for a Windows shop.

The learning curve isn't particularly steep here, an hour or less should bring someone up to a functional level with Git, and even though it does have a little trouble working with binaries effectively, particularly large ones, but that's a problem common to most version control systems. git-annex (http://git-annex.branchable.com/) might provide a serviceable workaround for large binary "assets", depending on your workflow, but I haven't used it myself.

EMC Syncplicity

[GWBasic]

EMC Syncplicity. Note: I am the desktop client lead.

Maybe something like git-annex is right for you?

[krakrjak]

You might want to checkout git-annex: http://git-annex.branchable.com/

It handles the idea of larger repositories with disconnected parts. You get git versioning of files and the ability to replicate portions of the data at will.

VisualSVN TortoiseSVN AnkhSVN

[egamma]

The developers at my company, who use windows laptops, keep a lot of their code in VisualSVN server and then use eitherAnkhsvn to do the checkout straight into Visual Studio, or TortoiseSVN if you want to be able to right-click in any folder and checkout to that location.

*GoodSync!

[Anonymous Coward]

http://www.goodsync.com/
Works like a charm, with directory-level sync control, and automatic resync on a schedule, if you want.

Mercurial

[mars-nl]

I see Git and SVN mentioned a lot, in positive and negative sense. I would suggest Mercurial, but is better than SVN (i.e. distributed) but easier to use for most SVN people than Git.

Unison?

[hobarrera]

I agree that a VCS is the best choice, as suggested above. If, for some reason, you don't want to use that (eg: too many binary files grow you repo too much), unison is a great choice. It uses rsync to sync files, and keeps track of which files where modified on which side.

Re:Unison?

[nick_urbanik]

I run unison from cron; it is hard to see how other people do without it.

Re:Wow, Windows is really still that bad?

[turbidostato]

"But why 'sync' stuff at all? Why not work directly on the file server (Z: in this case)? Why mess with 'local' files that will even need synchronization?"

Because that way each developer would step on each other's toe. I bet that when working on an idea they still go renaming their files like foo.1, foo.2, etc. and that more or less fortnightly if not more frequently there are discussions on why you didn't ask me about file bar, now you have overwritten it with your own incompatible version.

This people is discovering source code managing principles at their own pace.

I'd say they are more or less at the level of RCS days.

Re:Bittorrent Sync. Was: OwnCloud is pretty good

[ThaumaTechnician]

Agreed. And it only takes a minute ore two to set up.

Re:Wow, Windows is really still that bad?

[chuckinator]

As long as the system allows for concurrent deployment of multiple processes, multiple installation paths, and doesn't start services as daemons on conflicting ports, you can have hordes of developers on the same development server. This doesn't typically work well for OS, embedded, or resource intensive development projects, but it's a breeze for web projects and some basic application development. Still, this is 2013, and it costs less to get someone setup with a company laptop than it does to give them health insurance. The only reason to lock people into centralized development machines instead of a portable is about physical control of the source code, and that is an employer's prerogative if they so choose.

There are use cases for multiple systems, and sharp companies make use of as many of these systems to fill their niches as they need. Put up a source code management system like rcs/cvs/svn/git/mercurial/bazaar/sourcesafe/bitkeeper/etc. If you need a whiteboard area for people to track projects, requirements, milestones, and other cultural information that's good for employees to know, slap together a wiki. If you need a dumping ground for large amounts of junk media files and other random crap (this litters SCM and bloats on disk storage if it exceeds a certain threshold), then set up a shared Z: or H: drive by all means, but don't expect it to facilitate shared development on curated central libraries unless it's just temporary transferring files when a merge is too complicated. If you want to go the microsoft route and give thousands and millions to a software vendor, then do so by all means.

No tool is a golden hammer. No tool is the best for every job. If you try to make one tool do everything, you're setting yourself up for failure. Listen to other people and be willing to go along with solutions that you may personally resist at first if they give you confidence to believe they know what they're talking about (or they're signing your paychecks).

Too many subfolders

[chrismcb]

I'm curious about a couple of things. Of course pretty much everyone here is screaming "source control" But how is that you have a programmer working on THIRTY projects at one time? Perhaps I'm misunderstanding your use of "project" but I think I would go crazy if I was trying to juggle thirty different projects. Perhaps some sort of consolidation is in order.
You also mention if you sync the whole thing, navigation would be a problem with too many subfolders. A good source control will help alleviate this issue as a programmer could only checkout a portion of the system. But I think you have a bigger problem to solve if you have too many subfolders. Perhaps you need to solve your project hierarchy.

Re:Too many subfolders

[Koookiemonster]

We don't really do "traditional programming", so to speak. Instead we make building automation projects (like HVAC controls), and the workflow generally goes like this:

1) We make cabling lists for electricians 2) we make HTML graphics, do PLC programming (say 1 to 5 days for small projects), 3a) we wait ~6 months until electricians have finished cabling (they have to wait for construction workers) 3b) while also installing our own control devices and testing the software, 4) project is finished, but are often revisited to add new features, fix something, answer questions, ...

If someone calls us and asks e.g. what kind of valve is at location 13, project 154, it's difficult and slow to checkout the project first and then access some file. And If we keep everything synced at all times, it's about 200 projects and 6 GB of data. It's not great to have a 6 GB git project or 200 git projects that we'd have to juggle.

Also we know the current solution is technically really ugly, but it works. Even our manager knows how to press a button to sync everything. Or how to access/edit/add a document from a 4 yo project, while talking on the phone and leaving the office in 2 minutes. Also note we have 5 laptops (i.e. 5 people), but 3 programmers, so not everyone is so tech-savvy.

DFS

[BitZtream]

Seriously, learn to use it.

Problem solved.

Yes, SAMBA supports it.

Right click on the share, tell it to keep offline files or whatever. Then your users just use the Z drive regardless of when and where. When not connected the share, the cached copy works, when connected to the share, you're editing/locking the share's files.

Conflicts can happen, and you will be warned when they do. If thats a problem, you need a proper CVS (concurrent versioning system, not the actual CVS software specifically) I'd suggest cvsnt or subversion myself as they are simple to use for basic stuff. GIT is too techie for all but the most distributed of distributed geeks.

You Want Source Control, Not Synced Folders

[CodeBuster]

Seriously, only amateurs mess around with network shared and synced folders. Get yourself a revision control and source repository system. There are plenty to chose from. Take a look at Subversion or Mercurial to get started. Synced folders are link flint knives and bearskins. You need to up your game.

Slashdot worthy question?

[Anonymous Coward]

No offense, but StackOverflow...
Are SCM/VCS really such a hard thing to find out about that it deserves a Slashdot headline??

allwaysync

[icb1000]

I've been using the pro version of allwaysync (http://www.allwaysync.com) to do this kind of thing.

You can use regex to define which folders to use, does autosync, deletions etc...

regarding freefilesync

[Isaac Remuant]

I was going to potentially suggest it but saw you already use it.

Currently we use FreeFileSync with a custom piece of Javascript to make batch files that synchronize e.g. folders C:\projects\123_ProjectName\ and Z:\123_ProjectName\ if the local folder exists. However, that solution lacks versioning, real-time sync and deletion support. It only syncs when we press a button, and then older files are overwritten by newer files (two way sync; older files go to a "sync-deletions"-folder).

FreeFileSync HAS batch files that can run and you can always schedule jobs (at login, connection with server, etc). You can customize the sync and even use versioning. It supports names of drives instead of letters as well...

Anyway, I'll add to the voices that said that you need to use some sort of Source Control for projects. Even if it's only to be able to 'blame'.

Subversion and TortiseSVN works for us

[mixed_signal]

We have a network-attached storage drive, a Linux server and several developers using Windows laptops and a few fixed PCs. While it's possible to run Subversion (SVN) directly on the NAS, we run it on the Linux box for which we had already set up a secure tunnel method of access from outside. The Linux SVN repository is simply a link to the real repository on the NAS (which is RAIDed and also backed up more frequently). We run TortiseSVN on the PCs, both fixed and laptops. As others noted, developers only need to pull in the projects they need to their PCs. This is working really well, no hiccups at all and free to use. We've used CVS, Git and a few others and found this gave the best tradeoff of features and complexity for what we do. YMMV.