|
Suppose I'm sort of old fashioned and I want to setup a central server. How would I get started? Suppose I have a few users on different machines how would we get those repositories on the the central server? On the central server where should my files live? If it helps assume this is a windows server. |
On DVCS central serversIn my experience, the notion that a central server is "old fashioned" is a common misconception among people new to DVCS. Virtually every project has instances of a repository that are more important than others. We certainly do. So first, put aside the notion that you might be doing something wrong when you want to set up a server for use by a team! :) A Windows ServerToday, the dev team at SourceGear simply has a Windows machine with a user always logged in and vv serve --public running in a console. By default, this runs on port 8080 and requires no special permissions. If you want your server running on port 80, the Windows user running it will need special permissions. (Adding it to the local Administrator group works, but there's likely a less ham-fisted approach.) Then you can run vv serve --public --port 80. A more typical Windows server experience (e.g. IIS or a Windows Service) will come in future versions of Veracity. It will likely include paid components. Adding new repositories to a central serverVeracity currently has no ability to push a new repository to a server. This is deliberate, because there is currently no user permissions model, and allowing anybody to create a new repo remotely seems like a questionable idea. So instead, you clone to it: Have the developer with the new repository start up a server: From the central server, clone from the developer machine: The developer can then shut down his server (with CTRL-C), and the new repository is available on the central server. Ok "Old fashion" was a bit of a annoyance statement. I knew most people used central servers. But now I understand the key part of my question. To clone a repository from server to server must be a pull operation. That seems somewhat awkward but I'm cool with your explanation.
(Jul 18 '11 at 14:06)
acbova
It is a little bit awkward. When we have a user permissions model, a clone via push ought to be possible.
(Jul 18 '11 at 14:08)
Ian Olsen ♦♦
|
|
(I was mostly done composing this before ian made is reply, so fwiw here's another perspective.) Any computer with veracity installed on it can become a server by running the following command on the command line. This serves on port 8080 by default, but another port can be used by adding a Once a server is running, you can clone from it, using the This means that for any given repository, you will either need to create the repository on the central machine (using You do not need to worry about where your files should live on the central server. All of your repos will be stored in a "closet" folder created by Veracity ( To create an empty repository directly in the closet (without having a folder associated as a "working copy") you will need to use In summary:
This was quite a good answer. Thanks for it
(Jul 18 '11 at 14:09)
acbova
1
if you are on windows there is a command line utility call sc.exe that either comes with windows or is available via tools depending on your flavor. this can be executed to make it a windows service so you don't need to be logged into the box the entire time and should persist across reboots. I can't tell you the exact way to set it up since my favorite admin guy did it for me on our new in-house dev server.
(Aug 08 '11 at 21:03)
Rodzard
@Rodzard I tried a few times but didn't get it working. Is it possible to give some hints on how you started "vv.exe --public --port:12345" as a service? I installed it on a spare windows machine which has no monitor and no keyboard.
(Aug 12 '11 at 07:16)
Flynn
|
