сервер подверсии по сравнению с доступом сетевого хранилища через черепаху

Question

сервер подверсии по сравнению с доступом сетевого хранилища через черепаху

Хорошо, если вы хотите обновить файл, проверьте этот код:

const myUpdaterFcn = (dir,file,data,callback)=>{
           //dir looks like this: '/your/existing/path/file.json'

  // Open the file for writing (using the keyword r+)
  fs.open(dir, 'r+', (err, fileDescriptor)=>{
    if(!err && fileDescriptor){
      // Convert data to string
      const stringData = JSON.stringify(data)

      // Truncate the file
      fs.truncate(fileDescriptor,err=>{
        if(!err){
          // Write to file and close it
          fs.writeFile(fileDescriptor, stringData,err=>{
            if(!err){
              fs.close(fileDescriptor,err=>{
                if(!err){
                  callback(false)
                } else {
                  callback('Error closing existing file')
                }
              })
            } else {
              callback('Error writing to existing file')
            }
          })
        } else {
          callback('Error truncating file')
        }
      })
    } else {
      callback('Could not open file for updating, it may not exist yet')
    }
  })

}

Удачи.

6

sharing networking svn

задан Hammad Khan 13 February 2012 в 15:59

4 ответа

Другие вопросы по тегам:

sharing networking svn

Похожие вопросы:

score 22 · Answer 1

Да, Вы получили бы много: Вы снижаете риск потери всех Ваших данных!

См. документы (и предупреждения) о доступе к репозиторию на сетевом ресурсе.

score 2 · Answer 2

При доступе к репозиторию через URL file:/// библиотеки подверсии предположат, что репозиторий доступен на локальном диске и не попытается (или даже сможет) минимизировать сеть I/O. Доступ к репозиторию через svn:///URL поэтому намного быстрее для определенных операций, где много данных должно быть считано только для определения части, которая должна быть, отправляют клиенту, как имеет место для svn switch команда.

Я не смею говорить то же о доступе http://. http протокол относительно болтлив и неэффективен в svn 1.5. Существуют планы улучшить это для svn 1.7

score 1 · Answer 3

Да, Вы могли сделать несколько дополнительных вещей:

Дополнительные механизмы аутентификации (Основной автор по HTTP/S, ssh совместно использованный ключевой автор)
Используя Apache+mod_dav_svn можно настроить более прекрасное гранулярное управление доступом на пути основанием пути

править: Не уверенный, если Вы используете подверсию в настоящее время по доле файла или только используете простую долю файла. (SVN может использовать file:/// URIs также).

score 1 · Answer 4

Обычно Вы не "проверяете" файлы в SVN. Таким образом, Вы не блокируете их при работе над ними.

Вы получаете несколько вещей однако, (это только от вершины моей головы):

История фиксации (и на файл, и для репозитория как целый)
Опции ответвления/Слияния
Способность отметить версии (часто формальные выпуски)
Способность откатывать изменения в определенном пересмотре (например, если серьезная ошибка была недавно представлена),
и еще много

Отметьте однако, что большинство или все эти преимущества не уникальны для подверсии, но могут быть получены от большинства современных систем управления версиями.