Windows File Repository System?
July 10, 2007 7:31 AM Subscribe
Is there a windows file repository program that is simple to install?
I need a file repository program installed on a windows machine so that any computer on that network can acces its files accordingly. If one machine is using a file, the other machines will not be able to edit that file.
I am looking for something with a straight forward installation. I would liek to run an installer and have it pretty much ready to go.. or close to ready.
I need a file repository program installed on a windows machine so that any computer on that network can acces its files accordingly. If one machine is using a file, the other machines will not be able to edit that file.
I am looking for something with a straight forward installation. I would liek to run an installer and have it pretty much ready to go.. or close to ready.
Response by poster: I want something like CVS or SVN. CVS is giving me a lot of problems. Seems I am not experienced enough with this stuff to understand its installation and usage. SVN's exe file won't find Apache on my system so it is not installing properly.
So in short, yes, I do want a file-versionaning system.
posted by kaozity at 7:53 AM on July 10, 2007
So in short, yes, I do want a file-versionaning system.
posted by kaozity at 7:53 AM on July 10, 2007
Best answer: You don't need Apache to run a Subversion server. Instead, you can set up 'svnserve'. First, install the command-line Subversion tool. Then, enter a command like this at the command prompt:
sc create "svnserve" binpath= "c:\program files\subversion\bin\svnserve.exe --service --root C:\SVNRepo" displayname= "Subversion Server" depend= Tcpip start= auto
After than, start the "Subversion Server" service (using the 'Services' administration tool).
After that, you can use your favorite Subversion client (e.g., TortoiseSVN) to access the repository.
posted by Emanuel at 9:33 AM on July 10, 2007
sc create "svnserve" binpath= "c:\program files\subversion\bin\svnserve.exe --service --root C:\SVNRepo" displayname= "Subversion Server" depend= Tcpip start= auto
After than, start the "Subversion Server" service (using the 'Services' administration tool).
After that, you can use your favorite Subversion client (e.g., TortoiseSVN) to access the repository.
posted by Emanuel at 9:33 AM on July 10, 2007
I just started using tortoise. I like it a lot. You might like it too.
posted by waxboy at 9:34 AM on July 10, 2007
posted by waxboy at 9:34 AM on July 10, 2007
Oh, and that command-line assumes that you have already set up a repository in C:\SVNRepo. See the Subversion Book for details on setting up the repository and accessing it (hint: you will use the "svn://" protocol to access the repository).
Also, some flavours of windows don't include the 'sc' utility. You should be able to get it from a Windows Resource Kit.
posted by Emanuel at 9:38 AM on July 10, 2007
Also, some flavours of windows don't include the 'sc' utility. You should be able to get it from a Windows Resource Kit.
posted by Emanuel at 9:38 AM on July 10, 2007
Subversion doesn't sound like a good tool for this. It's default mode of working isn't about exclusive locking.
Each subversion user will have a working copy. Even if they lock the file they are editing in the main repository, they'll have to unlock it if they want people to be able to edit it once they check their changes in.
If the next person checking their changes in was working with an older version of the file there is going to be a conflict. If it's just a simple text file, they'll be able to merge their changes with the other changes. If it's a text file with a lot of markup, or a binary file, like a word document, etc then merging will be difficult or impossible.
I'm not sure the other options are any better. You really need application level awareness. Either the repository system needs to under stand the file format, or the application needs to understand the mechanics of file locking.
Microsoft office apps try to open files in read-write mode. If they can, then a properly functioning windows fileserver should lock the file for writing by any other user. If another user comes along and tries to open the file, office will try to open it read-write, when it fails, it will open it read only and will not let the second user save the file without using "Save As"
However, once the person with the original write lock closes the file, the second person can "Save As" using the same file name and overwrite their changes. Maybe you can train people not to do that, but I wouldn't count on it without having some automatic versioning too so someone can go back by hand and recover overwritten changes (if they realize they've been overwritten)
If you are using Windows Server 2003, look into shadow copies, which allow you to keep past versions of files automatically.
posted by Good Brain at 10:52 AM on July 10, 2007
Each subversion user will have a working copy. Even if they lock the file they are editing in the main repository, they'll have to unlock it if they want people to be able to edit it once they check their changes in.
If the next person checking their changes in was working with an older version of the file there is going to be a conflict. If it's just a simple text file, they'll be able to merge their changes with the other changes. If it's a text file with a lot of markup, or a binary file, like a word document, etc then merging will be difficult or impossible.
I'm not sure the other options are any better. You really need application level awareness. Either the repository system needs to under stand the file format, or the application needs to understand the mechanics of file locking.
Microsoft office apps try to open files in read-write mode. If they can, then a properly functioning windows fileserver should lock the file for writing by any other user. If another user comes along and tries to open the file, office will try to open it read-write, when it fails, it will open it read only and will not let the second user save the file without using "Save As"
However, once the person with the original write lock closes the file, the second person can "Save As" using the same file name and overwrite their changes. Maybe you can train people not to do that, but I wouldn't count on it without having some automatic versioning too so someone can go back by hand and recover overwritten changes (if they realize they've been overwritten)
If you are using Windows Server 2003, look into shadow copies, which allow you to keep past versions of files automatically.
posted by Good Brain at 10:52 AM on July 10, 2007
Good discussion on file locking models from the subversion book. Note the caveat at the bottom of the page.
Also you can deploy subversion on a shared filesystem without apache or svnserv.
posted by Good Brain at 10:58 AM on July 10, 2007
Also you can deploy subversion on a shared filesystem without apache or svnserv.
posted by Good Brain at 10:58 AM on July 10, 2007
This thread is closed to new comments.
posted by Tomorrowful at 7:43 AM on July 10, 2007