Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #4233 > unrolled thread

sitecopy-like software for FTP upload

Back to article view | Back to comp.programming

Contents

  sitecopy-like software for FTP upload Victor Porton <porton@narod.ru> - 2014-04-16 23:29 +0300
    Re: sitecopy-like software for FTP upload Kaz Kylheku <kaz@kylheku.com> - 2014-04-16 20:44 +0000
      Re: sitecopy-like software for FTP upload Victor Porton <porton@narod.ru> - 2014-04-17 00:02 +0300
        Re: sitecopy-like software for FTP upload Öö Tiib <ootiib@hot.ee> - 2014-04-21 05:00 -0700
        Re: sitecopy-like software for FTP upload Ian Collins <ian-news@hotmail.com> - 2014-04-23 16:19 +1200
          Re: sitecopy-like software for FTP upload Kaz Kylheku <kaz@kylheku.com> - 2014-04-23 04:39 +0000

#4233 — sitecopy-like software for FTP upload

Are there any sitecopy alternatives which do NOT overwrite modified files on 
the server?

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]

#4234

On 2014-04-16, Victor Porton <porton@narod.ru> 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.

[toc] | [prev] | [next] | [standalone]

#4235

Kaz Kylheku wrote:
> On 2014-04-16, Victor Porton <porton@narod.ru> 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?

Modification timestamp.

> 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.

OK, now I realize this can't be implemented outside of a text editor (which 
could remember mtime of a newly opened file to compare it with mtime on the 
FTP server).

Sorry for a stupid question.

> 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

Not using version control in our company is one of the reasons why I am 
going soon to send a query letter asking for a job to an other company. 
Certainly I prefer to work with version control.

> 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.

-- 
Victor Porton - http://portonvictor.org

[toc] | [prev] | [next] | [standalone]

#4258

On Thursday, 17 April 2014 00:02:08 UTC+3, Victor Porton  wrote:
> Not using version control in our company is one of the reasons why I am 
> going soon to send a query letter asking for a job to an other company. 
> Certainly I prefer to work with version control.

Write a script that round-trip syncs that FTP server with a Git repo and then
use Git repo. If others in your team are interested then share with them, 
rest can screw on with that FTP server.  If you can't because a policy is that
engineer may not choose even his own tools then walk away indeed.

[toc] | [prev] | [next] | [standalone]

#4284

Victor Porton wrote:
> Kaz Kylheku wrote:
>
>> 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
>
> Not using version control in our company is one of the reasons why I am
> going soon to send a query letter asking for a job to an other company.
> Certainly I prefer to work with version control.

Then why don't you?  Distributed version control tools like Mercurial or 
Git can be run locally.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#4285

On 2014-04-23, Ian Collins <ian-news@hotmail.com> wrote:
> Victor Porton wrote:
>> Kaz Kylheku wrote:
>>
>>> 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
>>
>> Not using version control in our company is one of the reasons why I am
>> going soon to send a query letter asking for a job to an other company.
>> Certainly I prefer to work with version control.
>
> Then why don't you?  Distributed version control tools like Mercurial or 
> Git can be run locally.

Wild-assed guess: others would have to be on board with the program, and those
others are, shall we say, hopelessly unsophisticated.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web