Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-06-07 07:02, Bo Berglund wrote:

So time stamp handling is not that important really it's just that I
observed the difference when comparing the GIT version of a project


Fair enough and a good observation.

Git stores such "metadata" like author name + email, authored timestamp, 
committer name + email, commit timestamp, commit message etc in the Git 
repository. File systems alone obviously can't handle such information. 
You can obviously query the Git repository for that information and 
because Git history is all local, it is very fast to retrieve - unlike 
SubVersion, TeamCoherence, CVS etc. that must query a remote server over 
TCP/IP.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-06-06 09:40, Bo Berglund wrote:

It seems like GIT does not like the fact that in CVS only changed
files can be committed thus revisions of files evolve on a file by
file basis. So when a CVS tag operation is performed the tag is
applied on all of the files in the current state. This means that a
CVS tag contains files at different revision levels and apparently
this is something GIT does not like.


I think Git is trying to make something good out of a bad situation. I 
wouldn’t blame git if it didn’t get things 100%. The way CVS and 
TeamCoherence (which was an improvement over CVS too) all applied 
revisions per file only, instead of a whole “repository state snapshot”. 
That behaviour was very pre-historic, [and personally] a terrible 
design. You could never get a decent snapshot of all files in the 
repository at a specific point in time. That was one of the major new 
features and improvements that even SubVersion introduced.



So it tries to "fix" this by making fake commits or something similar.


I guess it’s trying to fix a “hack” with a hack. ;-)



I can go elsewhere and clone the created repository at which time I
am getting the HEAD revision checked out. Relevant files compare fine


Perfect.



except they are not the correct timestamp.


Git only tracks file contents, and some extra commit related metadata. 
Timestamps are really irrelevant when it comes to managing file content 
changes over time.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Giuliano Colla]

Il 06/06/2017 10:40, Bo Berglund ha scritto:

Relevant files compare fine
except they are not the correct timestamp.


This is one of the down sides of GIT: it doesn't preserve timestamps.

As a workaround you may write a small script which will touch each file 
of the newly created repository with the time stamps of the original 
folders. Here enclosed a python script which I used for that purpose; 
you may see if it fits your needs.


After that, if you need to preserve timestamps, you may take advantage 
either of git-restore-time (which will change the timestamps to the 
commit time):


https://github.com/MestreLion/git-tools

or of the metastore utilities:

https://github.com/przemoc/metastore

which adds an additional metadata file, where original timestamps are 
stored, and used to properly set them at each commit, and to restore 
them at each checkout, pull, etc.


Hope that it helps,

Giuliano



#!/usr/bin/env python
# -*- coding: utf-8 -*-
import subprocess, shlex
import sys, os.path
from filecmp import dircmp

samelist = set()

def print_diff_files(dcmp):
	for name in dcmp.same_files:
		samelist.add(dcmp.left + '/' + name + '#' + dcmp.right + '/' + name)
	for sub_dcmp in dcmp.subdirs.values():
		print_diff_files(sub_dcmp)

if len(sys.argv) < 2:
	print "Missing source and/or dest. path. Aborting!"  
	sys.exit(1)

leftdir = sys.argv[1]
rightdir = sys.argv[2]

dcmp = dircmp(leftdir, rightdir)
print_diff_files(dcmp)

for file in samelist:
	fileb = file.split('#')[-1]
	filea = file.split('#')[0]
	print "filea: %s" % (filea)
	print "fileb: %s" % (fileb)
	mtime = os.path.getmtime(filea)
	os.utime(fileb, (mtime,mtime));
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Lukasz Sokol]

On 04/06/17 23:12, Bo Berglund wrote:
> Report on progress:
> I have found a way to convert CVS to GIT using the cvs2svn module,
> which contains a cvs2git file. It was described in this article:
> https://devsector.wordpress.com/2014/05/17/migrate-cvs-to-git-with-cvs2svn/
> 
[...]
> 
> I am worrying that I am doing this all wrong...
> 
> It is possible to clone the repo and get the expected file tree out,
> though.
> 
You have (probably) created the repo in 'bare' mode (no checked out working 
copy?)

(or the conversion process does it inadvertently) 

When you clone, you get the working directory, then you'd need to push changes 
to bare repo
(just like you would on SVN or CVS by default)

(hope it's that, idk because I don't use bare repos).

-L.

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-06-04 23:12, Bo Berglund wrote:

Why is the repo in this condition?
And what to do about it? Obviously going over it with
git reset HEAD ...
isn't really practical since this example project (an Android App)
contains deeply nested folder trees with hundreds of files.


Like I said, I have no experience with CVS or covertions from CVS-to-Git.

1) I suggest you start with a 'gitk --all' and see how the history
   of your repository looks like, and if there is any history at all.

2) You don't have to reset each file one by one. You can do it all
   in one go with:  git reset --hard

   But why all your files are marked for deletion is a mystery to
   me.

3) This is never mentioned in ANY repository conversion guides, but
   something I ALWAYS do. After you ran your automated migration to
   Git, I would use a comparison tool (eg: Beyond Compare) and
   compare a _clean_ original repository against the newly migrated
   Git repository. Do a new checkout of the original repository (CVS,
   Subversion etc) to make sure it is clean and you know it is the
   latest code from the server. Technically there should be NO
   differences, but on the small chance that there is, now is the
   time to see the differences and commit those into Git so you know
   going forward both repositories have the exact same state (at the
   time of migration).

Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Mark Morgan Lloyd]

On 30/05/17 14:30, Graeme Geldenhuys wrote:

On 2017-05-29 13:01, Mark Morgan Lloyd wrote:> I'd use something like an
HP> Microserver with at least mirrored discs,
Yes the HP Microservers are excellent! I highly recommend them, and they
are cheap as chips - so a real bargain. I would load it with good
NAT/Server style disks (eg: Western Digital Red disks) and a small SSD
boot disk (or even a USB stick). Run FreeBSD or Linux with ZFS in
RAID-z1 or RAID-z2. Like I said is some other thread, I wouldn't trust
my data on any other file system again - only ZFS for me! A all-in-one
easy to set up system is FreeNAS (which comes standard with ZFS) and
includes other since things like easy directory sharing via FTP, HTTP,
NFS etc. All managed via a simple web interface.


It appears that ZFS is also available for Debian "Stretch", and is in 
"Jessie" backports. That's the original Sun implementation, via BSD.


It would almost certainly need more than an RPi to do it justice though.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

Report on progress:
I have found a way to convert CVS to GIT using the cvs2svn module,
which contains a cvs2git file. It was described in this article:
https://devsector.wordpress.com/2014/05/17/migrate-cvs-to-git-with-cvs2svn/

Since our CVS server resides on Windows and is driven by CVSNT and the
conversion process (a Python system) uses the cvs executable to
extract revision information from the version files I decided to give
it a try on Windows7.
After some misunderstandings causing me to restart the conversions I
finally managed to convert some test projects.

But there is one very strange thing happening:
After the conversion is done according to the steps in the article
this happens when I run a check on the created GIT repo:

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD ..." to unstage)

deleted:SSM1/ReadMe.txt
 

Why is the repo in this condition?
And what to do about it? Obviously going over it with
git reset HEAD ...
isn't really practical since this example project (an Android App)
contains deeply nested folder trees with hundreds of files.

I am worrying that I am doing this all wrong...

It is possible to clone the repo and get the expected file tree out,
though.

Another issue is that it seems like the conversion of a CVS repository
consisting of many different modules ("projects" if you will) ends up
with a single huge GIT repo which can only be cloned in its
entirety...
How can one store multiple and *separate* projects in GIT?


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Fri, 2 Jun 2017 10:19:49 +0100, Graeme Geldenhuys
 wrote:

>On 2017-06-02 00:00, Bo Berglund wrote:
>> The beauty of this is that we do not need to duplicate common
>> functionality between projects as would be the case if we *copied* the
>> common files into the source folder. These files are used in many
>> places but versioned in a single place on the server.
>
>Yes, Git has that functionality too. It is called "submodules". Common 
>code can live and be maintained in it's own repository. Other 
>repositories can than link to that repository.
>
>   https://git-scm.com/book/en/v2/Git-Tools-Submodules
>
>   https://git-scm.com/docs/git-submodule
>
>I have used this often. If you clone a repository that makes use of 
>submodules, all the information is already there (stored inside the 
>repository).
>
>The first time you clone such a repository, it will not automatically 
>fetch the files from the submodule. You need to run (only once) the 'git 
>submodule init' command. Then every time you want to update the 
>"common/shared code" you run 'git submodule update'.
>
>The Pro Git chapter explains it very well, and it is actually quite 
>simple to setup and use.

Thanks a lot, found the chapter and will be going over it this
week-end with my son-in-law who uses GIT himself.
He did not know of the possibilities before, though. He recently
converted his SVN repo to GIT. But I think he has not used this
feature.
He also earlier told me to look at GIT as replacement for CVS.

-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-06-02 00:00, Bo Berglund wrote:

The beauty of this is that we do not need to duplicate common
functionality between projects as would be the case if we *copied* the
common files into the source folder. These files are used in many
places but versioned in a single place on the server.


Yes, Git has that functionality too. It is called "submodules". Common 
code can live and be maintained in it's own repository. Other 
repositories can than link to that repository.


  https://git-scm.com/book/en/v2/Git-Tools-Submodules

  https://git-scm.com/docs/git-submodule

I have used this often. If you clone a repository that makes use of 
submodules, all the information is already there (stored inside the 
repository).


The first time you clone such a repository, it will not automatically 
fetch the files from the submodule. You need to run (only once) the 'git 
submodule init' command. Then every time you want to update the 
"common/shared code" you run 'git submodule update'.


The Pro Git chapter explains it very well, and it is actually quite 
simple to setup and use.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Lukasz Sokol]

On 01/06/17 09:12, Graeme Geldenhuys wrote:
> On 2017-05-31 08:33, Lukasz Sokol wrote:
>> TortoiseGIT also lets you create a 'bare' repo.
> 
> I don't disputed that, and I don't mind others using gui front-ends
> to git - as long as they know they are seriously limiting their
> abilities and functionality of Git.

It wasn't my intention to 'dispute' anything, only just to point that out. :)

> 
> I have reviewed a lot of Git GUI front-ends in depth over the years.
> In every single case they lagged behind Git command line interface
> features or couldn't do some of the more advanced functionality. And
> more often than not they got confused about the state of the git
> repository. They were also always slower to use than the command line
> interface.
> 

I have TortoiseGIT 1.8.16.0 with git 2.8.2.windows.1... on winxp it's the last
revision I can use (starting with TGit 2.0 winxp support is removed)

But, it's (or, it 'Feels') much faster.

At least compared to TSVN 1.6.5 with SVN 1.6.5 i also have on that machine.
(plus, this needs a special area to hold the 'bare'/repo 'remote' directories, 
or a server,
which git doesn't need that badly)

As per features, I'm probably not even using 5% of them... but it lets me 
get used to having them, in case I need them later on;

I remember looking at TGit when it was not yet 'on par' with git's own features
(pre-1.0 TGit) and it wasn't as impressive as it is now.

And having just tried that-era (2.8.2.windows.1) git-bash, on my winxp sp3,
 I can't say I'm impressed with its speed... even ls -l is a 1-2s delay...
(that may or may not apply to git itself though, it just discourages me from 
trying it).

> Regards, Graeme
> 
Kind Regards
-L.

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

Continuing with GIT...

I am now studying a few on-line documents outlining the conversion of
a CVS repository to GIT. There is a script suite named cvs2svn with a
number of specific scripts for various targets like cvs2git, so I
think I can use this. But I think I have found a problem, which may or
may not exist, but I need to check:

We use the CVS modules concept a lot in our CVS repository. It
virtualizes programming projects by collecting files from various
"common" modules into a target structure for the project itself.
We have as example a CommonFiles module, which contains 26 files
implementing various commonly needed functions.
In any given actual project the specific source files for that project
is stored as a named module of files.

Now the module definition in CVS collects the files and folders from
various places into the structure of the project itself, often placing
the files for the actual project into a "source" folder. The common
files are placed in separate folders next to the source folder in the
checkout.
The net effect is that we have these specific and common files
collected into folders in the work project folder ready to be worked
on.

The beauty of this is that we do not need to duplicate common
functionality between projects as would be the case if we *copied* the
common files into the source folder. These files are used in many
places but versioned in a single place on the server.

What would be the corresponding GIT method for this?
Or is it even possible?


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-05-31 08:33, Lukasz Sokol wrote:

TortoiseGIT also lets you create a 'bare' repo.


I don't disputed that, and I don't mind others using gui front-ends to 
git - as long as they know they are seriously limiting their abilities 
and functionality of Git.


I have reviewed a lot of Git GUI front-ends in depth over the years. In 
every single case they lagged behind Git command line interface features 
or couldn't do some of the more advanced functionality. And more often 
than not they got confused about the state of the git repository. They 
were also always slower to use than the command line interface.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Wed, 31 May 2017 23:04:02 +0200, Bo Berglund
 wrote:

>Now remains to find out how to disable the old version shipped with
>Raspbian and use the self-compiled newer version.
>The $PATH location seems not to help.
>

Problem solved but not understanding why...
I logged off the PuTTY session and then back in again and now the
command returns the correct value:

$ git --version
git version 2.13.0.311.g0339965

Even though it now works it would be intersting to know *why* I had to
log off and back on for it to use the path ...


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Wed, 31 May 2017 15:42:48 -0400, wkitt...@windstream.net wrote:

>On 05/31/2017 02:13 PM, Bo Berglund wrote:
>> the response to git --version is still
>> 2.1.4
>> 
>>  From where does this come???
>
>
>at the command line, type in "which git" without the double quotes...

$ which git
/home/pi/bin/git

This is the version I have built myself from sources and it is 2.13
I installed it into the user space rather than into /usr/bin/

However if I do:
$ git --version
git version 2.1.4


But if I do:
$ /home/pi/bin/git --version
git version 2.13.0.311.g0339965

Do you now understand my confusion?
Executing git on the command line seems to execute the /usr/bin/git
instead of the first git on PATH! /home/pi/bin is first on $PATH

Seems like git is started in /usr/bin and there it is getting the
erroneous version information
Why?


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[wkitty42]

On 05/31/2017 02:13 PM, Bo Berglund wrote:

the response to git --version is still
2.1.4

 From where does this come???



at the command line, type in "which git" without the double quotes...


--
 NOTE: No off-list assistance is given without prior approval.
   *Please keep mailing list traffic on the list unless*
   *a signed and pre-paid contract is in effect with us.*
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-05-31 16:10, Bo Berglund wrote:

The apt-get version of the git I use now is:
~/ $git --version
git version 2.1.4


Yeah, that is a rather old version. The latest is v2.13.

  $ git tag

will show all tagged releases. Just look for the latest one. You can 
also use 'gitk --all' and see what the "next" branch follows on from. In 
the Git project, the "next" branch is what will become the next release.


So simple checkout "next" or if you want a mare stable released version, 
checkout the v2.13 release.


  git checkout v2.13.0

(git will mentioned you have a detached HEAD, but that doesn't matter, 
it just means you don't have a local branch that matches that release 
commit.)




Is it not påossible to put docs and info below the ~/ dir?
According to the INSTALL file on the subject of Git install it says:


Yes, it works like most Makefile based environments - and is also 
mentioned in the INSTALL file You need to specify the install prefix 
directory.


  $ make prefix=/home//

Or whatever you want the install prefix to be.

As for building the Git documentation. Yes, that has extra dependencies, 
and from memory takes quite long to build. But the process is very 
similar to building the Git binary itself. All the instructions are in 
the INSTALL file.



Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Wed, 31 May 2017 10:58:29 +0200, Bo Berglund
 wrote:

>>I always install git 
>>from source code and compile it myself (like I do with FPC and Lazarus 
>>too). Everything is then included - as it should be. Linux distros f*ck 
>>everything up and split it into multiple packages. eg: git-core, 
>>git-base, git-gui, git-subversion, git-docs etc.
>
>I also build my FPC/Lazarus installations from svn sources since a
>couple of years. But only on Linux, I have not tried it on Windows
>yet.
>
>So I really should go back to the RPi and remove the git I installed
>yesterday and instead try to get the sources (via Subversion?) and
>build myself then? Is it possible to get the GIT sources without GIT?

Stupid question by me...
I should use git to get git sources *before* I uninstall the apt-get
version of git. The solution is in page:
https://git-scm.com/downloads
as this command:
git clone https://github.com/git/git

I used it and it finished successfully in a rather short time.

What I received is the latest *development* version, but if I got the
idea behind GIT I should now have a git repo locally on my RPi3 and
should be able to retrieve the latest released version of git from
that, right?
If so how do I move forward and find the release, update to it and
then build and install git from the sources?

The apt-get version of the git I use now is:
~/ $git --version
git version 2.1.4

Seems a bit oldish so I updated the RPi3 according to the ProGIT book
section 1.5:

sudo apt-get install dh-autoreconf libcurl4-gnutls-dev libexpat1-dev
gettext libz-dev libssl-dev

Then tried to make as per the INSTALL file. Ran for some time and
succeeded.
So I then also got requirements for the other stuff:

sudo apt-get install asciidoc xmlto docbook2x getopt

But it failed with this error:
E: Unable to locate package getopt

so I removed getopt from the install and all other modules installed
fine.

Then I did:
make configure
./configure
make all doc info
make install install-doc install-html install-info

The last line failed as follows:

 $ make install install-doc install-html install-info
SUBDIR git-gui
SUBDIR gitk-git
SUBDIR perl
SUBDIR templates
install -d -m 755 '/usr/local/bin'
install: cannot change permissions of ‘/usr/local/bin’: Operation not
permitted
Makefile:2408: recipe for target 'install' failed
make: *** [install] Error 1

Is it not påossible to put docs and info below the ~/ dir?
According to the INSTALL file on the subject of Git install it says:

Git installation

Normally you can just do "make" followed by "make install", and that
will install the git programs in your own ~/bin/ directory.

This is exactly what I would like to do instead of putting it below
/usr

What do I do next?


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Wed, 31 May 2017 01:03:54 +0100, Graeme Geldenhuys
 wrote:

Graeme, I am very grateful for your contribution to this discussion!
Aplogies if my postings are a bit longish, but I try to convey my
concerns and ignorance...

>> So this should not be created inside some user home then?
>
>You can create Git repositories wherever you want and have read/write 
>access. My "/data" path is simply by 8TB ZFS data pool, where I do all 
>my work and store all vital data. You can use your $HOME directory 
>(whatever that translates to on your OS) just as well.

In the end, if all works out well, I want to have a GIT *server* on
our company network as the main repository, acessed via the internal
network by authenticated developers only. It would be the "remote"
mentioned in several GIT how-to pages I have read.
There should be no access path to this from the Internet except for
developers with a VPN channel into the company network. But this is of
course not an Internet access path since the VPN effectively places
you inside the local LAN.
Access via http would probably be the simplest way to manage I
believe.

The Smart-HTTP server setup is mentioned in section 4.6 of the ProGIT
book:
https://git-scm.com/book/en/v2/Git-on-the-Server-Smart-HTTP

I found that Apache is already installed as part of the Raspbian
Jessie PIXEL so the install steps need not be done I assume.
However, the configuration instructions here are a bit terse so I have
not dived in there yet, need to get to know GIT better first.
But do you think it can be a working solution for us to use the web
interface? It would get a user authentication mechanism in place


>If you are going to share your Git repositories stored on your system 
>with the public

Will never happen. We work on products that we sell and we do not
share our code...

>You mentioned you wanted to play around with Git and get to grips with 
>it - hence I suggested a local setup without the need of a RPi or some 
>other device.

Since it looked very much like a Linux thing it appeared to me to be
simpler if I had a Linux box to test on. And I have found that RPi3 is
pretty convenient.

>I always install git 
>from source code and compile it myself (like I do with FPC and Lazarus 
>too). Everything is then included - as it should be. Linux distros f*ck 
>everything up and split it into multiple packages. eg: git-core, 
>git-base, git-gui, git-subversion, git-docs etc.

I also build my FPC/Lazarus installations from svn sources since a
couple of years. But only on Linux, I have not tried it on Windows
yet.

So I really should go back to the RPi and remove the git I installed
yesterday and instead try to get the sources (via Subversion?) and
build myself then? Is it possible to get the GIT sources without GIT?

Is there some additional task to perform before running make? Like for
FPC/Lazarus I had to script the install to make sure the system was
updated with extra libraries and such before building...

>> I would very much like to have a PDF copy since I usually find that
>> easier to read than using on-line webpage versions of books.
>> Could not find the PDF though...
>
>I just had a look. The links used to be on the Table Of Contents page, 
>but for some odd reason they aren't there any more. No stress, The 
>Internet Archive always comes to the rescue.
>
>  PDF:
>https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit-en.1084.pdf

Thanks Graeme!
Now I have the PDF ready for off-line reading (500+ pages...)

I have additional questions regarding the way GIT works:
Handling of line endings
-
When woking on multiple platforms like Linux, Mac and Windows there
has always been a struggle to get source code line endings compatible
with the platform. Windows uses CR-LF, Mac uses CR and Linux uses LF
and in some cases if this is wrong the sources will not work.
In CVS this was managed by the CVS client such that it expanded line
endings to the platform standard whereas the repository always used
the Linux standard LF.
So if sources were transferred between systems via CVS all was fine.

Now I have read a bit about GIT and it really looks like it checksums
whole files with a 40 char hash, which is used as the key to the
files. This would make the exact same file (content wise) on Linux and
say Windows appear different with different hash values unless there
is some mechanism in GIT that handles this.
But I have not seen any mention of this yet...
And how does one specify the type of file to put in GIT? I want to
keep also some binaries there, but these invariably contain CR, LF and
CRLF byte combinations that MUST NOT be changed when moving between
platforms...
Of course some tools may have provisions for line ending invariance
but for example php code breaks on Apache if these are wrong.
Does Lazarus or FPC ignore line ending differences?

And lastly regarding CVS conversion:

Since 

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-05-30 22:19, Bo Berglund wrote:

Since my local system is a Windows 7 laptop I have to resort to an RPi
to get the Linux system for which the commands are native...


Git is native on all supported platforms now.




  mkdir /data/myremote.git
  cd /data/myremote.git
  git init --share --bare .


When you install Git under Windows using the official installer, it 
includes Bash Shell integration and a shortcut on the desktop. So the 
above commands will work as-is on Windows too.


But you can obviously run a non-Bash shell/console under Windows. Then 
simply replace the Unix-style paths with Windows variants. The git-init 
command stays the same.




So this should not be created inside some user home then?


You can create Git repositories wherever you want and have read/write 
access. My "/data" path is simply by 8TB ZFS data pool, where I do all 
my work and store all vital data. You can use your $HOME directory 
(whatever that translates to on your OS) just as well.


If you are going to share your Git repositories stored on your system 
with the public, then better make sure you set up your system's file 
permissions correctly, or use a dedicated "shared location" on your 
system. Alternatively don't make your laptop or desktop directly 
accessible to the public on the Internet, instead push your repository 
to a public and secure server somewhere (eg: Github, SourceForge etc).


You mentioned you wanted to play around with Git and get to grips with 
it - hence I suggested a local setup without the need of a RPi or some 
other device.




I have read a few chapters on-line, including installing git using the
command:
sudo apt-get install git-all

which (of course) differs from the commands I have found in various
other how-to pages concerning git...


The Linux distros are to blame for that - more specifically ther 
incompatible "package management requirements". I always install git 
from source code and compile it myself (like I do with FPC and Lazarus 
too). Everything is then included - as it should be. Linux distros f*ck 
everything up and split it into multiple packages. eg: git-core, 
git-base, git-gui, git-subversion, git-docs etc. G*d damn ridiculous if 
you ask me!




I would very much like to have a PDF copy since I usually find that
easier to read than using on-line webpage versions of books.
Could not find the PDF though...


I just had a look. The links used to be on the Table Of Contents page, 
but for some odd reason they aren't there any more. No stress, The 
Internet Archive always comes to the rescue.


This is how it used to look like around 01 March 2017.

  http://web.archive.org/web/20170301183218/https://git-scm.com/book/en/v2


The individual eBook downloads from that page still works though.

 PDF:
   https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit-en.1084.pdf

 ePub:
   https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit-en.1084.epub

 Mobi:
   https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit-en.1084.mobi

 HTML:
   https://progit2.s3.amazonaws.com/en/2016-03-22-f3531/progit-en.1084.zip


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Tue, 30 May 2017 15:37:30 +0100, Graeme Geldenhuys
 wrote:

>On 2017-05-30 06:53, Bo Berglund wrote:
>> OK, I did not have in mind to use an RPi3 as the final system. I just
>> wanted to acquaint myself with GIT using a small portable unit over
>> the summer.
>
>In that case, you don't even need a RPi... Simply practice by doing the 
>following on your local system:

Since my local system is a Windows 7 laptop I have to resort to an RPi
to get the Linux system for which the commands are native...

>   mkdir /data/myremote.git
>   cd /data/myremote.git
>   git init --share --bare .

So this should not be created inside some user home then? In some
documents I found a new user "gituser" is created and in his home is
where they placed the master repository.

>You just created your remote [bare] git repository. The term "bare" 
>means that there is no checked out files. If you view that directory it 
>simply shows all the normally hidden files that git uses to manage a 
>repository.
>
>Now for your working repository where you will do you day-to-day commits:
>
>   cd /data/devel/
>   git clone /data/myremote.git/ mywork
>
>You will now have a Git repository in /data/devel/mywork/ which is a 
>clone of the /data/myremote.git repository. It as automatically set up 
>the "origin" as your Remote Git Repo. So if you to a git-push, the data 
>will go to "origin"
>
>Now playing around in this "mywork" repository. Create commits and 
>branches. Then do a git-push and magically you will have updated the 
>"origin" remote git repo too (which in this case is /data/myremote.git/)
>
>What you learn here, is exactly how you would do things with a real 
>remote repository.
>
>I highly recommend everybody interested in using Git reads the free and 
>open source "Pro Git" book [https://git-scm.com/book/en/v2]. It is 
>available online or offline in various formats (PDF, ePub etc). Is is 
>well written, fast to read and with tons of real-world Git examples.

I have read a few chapters on-line, including installing git using the
command:
sudo apt-get install git-all

which (of course) differs from the commands I have found in various
other how-to pages concerning git...

I would very much like to have a PDF copy since I usually find that
easier to read than using on-line webpage versions of books.
Could not find the PDF though...


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Dimitrios Chr. Ioannidis via fpc-other]

Hi,


On 30/5/2017 5:19 μμ, Graeme Geldenhuys wrote:

Run FreeBSD or Linux with ZFS in RAID-z1 or RAID-z2.


What a coincidence, we scheduled to test OmniOS with napp-it in a HP 
MicroServer .  ;)


https://www.napp-it.org/downloads/omnios_en.html .


regards,

--
Dimitrios Chr. Ioannidis
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Giuliano Colla]

Il 29/05/2017 13:00, Bo Berglund ha scritto:


Any suggestions on where to start?


My suggestion would be to use http://rogerdudler.github.io/git-guide/ as 
a quick reference just to have at hand the syntax of the most used 
commands, together with the links to the full documentation.


IMO a new user should be aware from the beginning of the usage of the 
.gitignore file, to tell what you don't want to track with GIT. Failing 
to use it, you may have your logs cluttered with bak files you don't 
care about, maybe object files you'd rather rebuild if such is the case, 
and so on.


A thing that I find very annoying with Git is that when you clone a 
repository, or you fetch from a repository, the dates of the files 
aren't preserved, which makes it impossible to tell apart at a glance 
what has been recently changed from what is old.

If this is important for you, you have at least two tools available:

 * the MestreLion git-tools (https://github.com/MestreLion/git-tools)
   providing git-restore-mtime which will change the time-stamp of all
   files to their commit time
 * The Metastore utility which you may get from
   https://github.com/przemoc/metastore. It adds a .metadata file in
   your repository, with the original datestamps of your files which
   are updated at ech commit, and it uses to restore the proper date at
   each checkout/pull request, provided you add the post-checkout and
   pre-commit scripts (which are supplied in the examples folder) in
   the .git/hooks/folder of each user.

I agree with others that an HP Microserver would be a very good choice, 
as an alternative (or as an addition) to a Linux VM in a Windows 
machine. Never put all your eggs on the same basket! Also an external 
USB HD should be considered as an inexpensive security backup.


Giuliano
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-05-30 06:53, Bo Berglund wrote:

OK, I did not have in mind to use an RPi3 as the final system. I just
wanted to acquaint myself with GIT using a small portable unit over
the summer.


In that case, you don't even need a RPi... Simply practice by doing the 
following on your local system:


  mkdir /data/myremote.git
  cd /data/myremote.git
  git init --share --bare .

You just created your remote [bare] git repository. The term "bare" 
means that there is no checked out files. If you view that directory it 
simply shows all the normally hidden files that git uses to manage a 
repository.


Now for your working repository where you will do you day-to-day commits:

  cd /data/devel/
  git clone /data/myremote.git/ mywork

You will now have a Git repository in /data/devel/mywork/ which is a 
clone of the /data/myremote.git repository. It as automatically set up 
the "origin" as your Remote Git Repo. So if you to a git-push, the data 
will go to "origin"


Now playing around in this "mywork" repository. Create commits and 
branches. Then do a git-push and magically you will have updated the 
"origin" remote git repo too (which in this case is /data/myremote.git/)


What you learn here, is exactly how you would do things with a real 
remote repository.


I highly recommend everybody interested in using Git reads the free and 
open source "Pro Git" book [https://git-scm.com/book/en/v2]. It is 
available online or offline in various formats (PDF, ePub etc). Is is 
well written, fast to read and with tons of real-world Git examples.


Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Graeme Geldenhuys]

On 2017-05-29 12:00, Bo Berglund wrote:

Is there a good way to set up an RPi3 box as a GIT server and get
going with that?

Can GIT work in a way that would be comparable to CVS regarding
concurrent development etc?

Any suggestions on where to start?


Git doesn't require a "server" - there is no "git server" like you find 
with CVS or SubVersion. Gitolite is a very fast and simple solution to 
get a shared Git environment up and running in the traditional 
client/server model that CVS and SubVersion users are used to. A true 
distributed environment will have no single "server location" of the 
source code.


There is a Git Daemon that can be run on Unix or Windows systems. But 
this is in essence just to supply you with access to a Git repository 
via the much more efficient git:// protocol, instead of abusing the 
http:// protocol.  The recommended way to access a Git repo is via SSH 
(which Gitolite also uses). You supply you public key, and don't have to 
bother with usernames and weak passwords.




Regards,
  Graeme

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Bo Berglund]

On Mon, 29 May 2017 12:01:32 +, Mark Morgan Lloyd
 wrote:

>On 29/05/17 11:12, Bo Berglund wrote:
>
>> TestingSo I thought that one way to go forward was for me to use an 
>> RPi3 boxas a repository server with GIT or whatever (seems like the 
>> CVSsuccessor SVN is now also on the decline...).Is there a good way to set 
>> up an RPi3 box as a GIT server and getgoing with that?
>> Can GIT work in a way that would be comparable to CVS regardingconcurrent 
>> development etc?
>> Any suggestions on where to start?
>
>Frankly, and after having run an RPi3 as my desktop system for roughly 
>nine months, I'd not use an RPi for that. I'd use something like an HP 
>Microserver with at least mirrored discs, and I'd make sure that I was 
>able to write a consistent snapshot onto something like a USB stick 
>storage device.
>
>My recollection is that while you can set up (software-controlled) 
>mirrored devices on an RPi, you run into problems mounting them at boot 
>time due to deficiencies in the loader- that was certainly the case when 
>I looked at it in the latter part of last year, although low-level 
>firmware improvements (roughly last November) might have fixed some of that.
>
>In addition, it's becoming increasingly obvious to many people that the 
>power arrangement is manky, and that you risk permanent damage to an 
>SDCard if inserting a USB device briefly pushes the voltage out of spec- 
>see discussion of the vcgencmd command.
>
>Finally, you /will/ need to backup, and if you've accumulated any amount 
>of data you really don't want to try doing that through a single 
>(internal) USB hub with no possibility of expansion.

OK, I did not have in mind to use an RPi3 as the final system. I just
wanted to acquaint myself with GIT using a small portable unit over
the summer.
If it did work and I found it useful I would put a Linux server on our
VMWare box and use that as the new versioning server. But over the
summer I am moving to a place where space is limited and I thought a
small box like a Pi3 could work as a test bed.


-- 
Bo Berglund
Developer in Sweden

___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] GIT versioning server on Raspberry Pi?

[Mark Morgan Lloyd]

On 29/05/17 11:12, Bo Berglund wrote:


TestingSo I thought that one way to go forward was for me to use an 
RPi3 boxas a repository server with GIT or whatever (seems like the 
CVSsuccessor SVN is now also on the decline...).Is there a good way to set up 
an RPi3 box as a GIT server and getgoing with that?
Can GIT work in a way that would be comparable to CVS regardingconcurrent 
development etc?
Any suggestions on where to start?


Frankly, and after having run an RPi3 as my desktop system for roughly 
nine months, I'd not use an RPi for that. I'd use something like an HP 
Microserver with at least mirrored discs, and I'd make sure that I was 
able to write a consistent snapshot onto something like a USB stick 
storage device.


My recollection is that while you can set up (software-controlled) 
mirrored devices on an RPi, you run into problems mounting them at boot 
time due to deficiencies in the loader- that was certainly the case when 
I looked at it in the latter part of last year, although low-level 
firmware improvements (roughly last November) might have fixed some of that.


In addition, it's becoming increasingly obvious to many people that the 
power arrangement is manky, and that you risk permanent damage to an 
SDCard if inserting a USB device briefly pushes the voltage out of spec- 
see discussion of the vcgencmd command.


Finally, you /will/ need to backup, and if you've accumulated any amount 
of data you really don't want to try doing that through a single 
(internal) USB hub with no possibility of expansion.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other