This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Check out things like Dropbox, which is a step beyond what you actually need. Basically it hooks into the OS: a file is written to the local dropbox folder, then it gets synced on their machine and all other dropbox machines. In your case it'd be a metadata hook: change the metadata, throw the metadata at a web service that collects it (filename, tags, whatever else you want). The web app would just aggregate the metadata in whatever form you need.
Joined: Feb 20, 2007
That would be a client dependent approach, won't it? Is it possible to build it without any client dependency? There is to be no program or configuration on client side.
My requirements sound demanding, but they have to be met!!
Your choices, then, are limited to the ones already mentioned. Although I still don't get the point, and it seems like a *lot* of work for the user if the native metadata can't be retrieved.
Joined: Feb 20, 2007
Ok, let me explain in detail what I am trying to do...
We are using Subversion as the code repository. What I observed in the large projects, having more than 15 programmers/developers working, that there are a lot of file merge issues. In ideal scenario, one should lock file and work, but that doesn't happen everytime, especially given the tight deadlines to deliver.
I thought of creating a web app, which could bring in the entire Subversion repository, and then users could enter comments at file and folder level to flag that node. The system would not enforce anything, but just show updates for each node. A user can flag a file or folder as locked, but it would be a notional and not a real flag. This is to be integrated in the developer's network. I have the SVN API in place.
The app is to be extended for user machines too, hence needs to be generic. This is more for learning and internal usage, but timelines given to me are like an actual project.
If there are *that* many file conflicts, then things aren't being integrated often enough and/or the code has no regard for separation of concerns. In my opinion you're trying to solve a problem that's already been solved in a much cleaner way.