Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Kaz Kylheku Newsgroups: comp.programming Subject: Re: sitecopy-like software for FTP upload Date: Wed, 16 Apr 2014 20:44:48 +0000 (UTC) Organization: Aioe.org NNTP Server Lines: 32 Message-ID: <20140416133631.729@kylheku.com> References: NNTP-Posting-Host: X+c6YNb3AaWMPA3YfA4opg.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: slrn/pre1.0.0-18 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.programming:4234 On 2014-04-16, Victor Porton wrote: > Are there any sitecopy alternatives which do NOT overwrite modified files on > the server? This bullshit again? Okay I will bite twice. What attribute of the file on the server indicates that it is "modified"? How would this alternative program detect that a file is "modified" and avoid writing to it? We connect to the server, log in, and there is a file. It has a modification timestamp, permission, ownership ... Which of these tells us that it is modified? Of course, you mean "modified relative to a prior version based on which you made changes." So to check this, we have to download the latest file from the FTP server, compare to that ancestral version, and if they match, then copy the new version (or else do a three-way merge with GNU diff3 or whatever). And we have to ensure that do this atomically somehow; so that nobody else can log in concurrently and sneak in their version. I don't understand why you and your colleagues don't use version control and put in place a release process whereby some designated person who currently holds the "release master stick" checks out a baseline from version control and FTP's it up to the server. This person could actually be a script that runs periodically or is triggered by commits to the master repo. Your master repository doesn't have to be on that server under the admin's control; it can be on a machine that is under the control of you and your collaborators.