subject:"Re\: \[fpc\-other\] Git \& SVN"


On 2017-05-24 21:07, Florian Klämpfl wrote:

I'm sorry to bust your bubble, but how different can compiler
development be.


Apparently it is:


Then why are you still talking to me.

I have my doubts that it can be _that_ different. To quote Marco "I see
to proof to make me think otherwise".



The workflow will not change. If the tool does not fit the workflow,
it is the wrong tool. Period.


Yes, habits (good or bad) are a hard thing to break. In that case, 
please enjoy your project further with SubVersion. Until you actually 
use a project with Git (not git-svn), we might talk again. But like you, 
I'm not holding my breath. ;-)



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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Nikolay Nikolov




On 05/24/2017 02:12 PM, Graeme Geldenhuys wrote:

On 2017-05-24 02:11, nore...@z505.com wrote:

I'd rather upload/commit files to a server to insure it is backed up
properly...


There is absolutely no guarantee that your file are any safer. So you 
have your Army of Developers in a single building. You store all your 
files on a Server which is in the server room in the basement of the 
building behind steel doors. Oh wait, a Boeing 747 fully fuelled just 
flew into your building. Everything is now a pile of rubble. Oh the 
backups where on another server next to the one you pushed changes to.
What if you have backups, distributed all over the globe? Oh wait, a 
meteorite hits Earth and wipes out all life. Everything is now a pile of 
rubble. Oh the backups where all stored on the same planet and now they 
are gone. :)


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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Marco van de Voort

In our previous episode, Florian Kl?mpfl said:
> > If you haven't found the Git project documentation on this workflow, I'll 
> > find it for you and post
> > the URL.
> 
> The workflow will not change. If the tool does not fit the workflow, it is 
> the wrong tool. Period.

Even if we will change workflow more GIT like in time, the required leap of
faith and transition is too large. 

I think the Git advocatists should focus more on a workable model for a
transition and not some ideal in the far future.

Even a limited change is already a massive operation, let's keep it
managable.
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

2017-05-24 Thread Florian Klämpfl

Am 24.05.2017 um 21:34 schrieb Graeme Geldenhuys:
> On 2017-05-24 19:11, Florian Klämpfl wrote:
>> You never developed a real world compiler and you have no real
>> insight into fpc development so you cannot know about this.
> 
> As a technical consultant for many clients I have seen a boat load of 
> projects from banking to
> online trading to educational etc. 

So no compiler? ...

> I'm sorry to bust your bubble, but how different can compiler
> development be. 

Apparently it is:

Am 23.05.2017 um 01:53 schrieb Graeme Geldenhuys:

>
> I don't know compiler design or how it works internally. So contributing in 
> that area is out of my
> scope.

:)

> If you haven't found the Git project documentation on this workflow, I'll 
> find it for you and post
> the URL.

The workflow will not change. If the tool does not fit the workflow, it is the 
wrong tool. Period.

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

Re: [fpc-other] Git & SVN


On 2017-05-24 19:11, Florian Klämpfl wrote:

You never developed a real world compiler and you have no real
insight into fpc development so you cannot know about this.


As a technical consultant for many clients I have seen a boat load of 
projects from banking to online trading to educational etc. I'm sorry to 
bust your bubble, but how different can compiler development be. I'm not 
talking about the recursive build process, I'm talking about bug fixes 
and implementing new features.




Who tests and signs? Our testing facilities cannot test more than a
few (1, 2 maybe 3) branches nightly as we use build farms used also


Like the Git project, you can merge all new work into a testing branch. 
That could be what "trunk" is now. Once features have been tested by FPC 
core members or community - using that trunk branch, those signed off 
features can be merged into a more stable development branch... lets 
call it "develop" (or in terms of the Git project, call in "next"). The 
"next" branch will always be more stable that "trunk". The "next" branch 
is also the one the next release (hence the name) will be based forked from.


If you haven't found the Git project documentation on this workflow, 
I'll find it for you and post the URL.


I think actually the 'git help workflows' command lists that same 
information.



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 & SVN

2017-05-24 Thread Florian Klämpfl

Am 24.05.2017 um 08:57 schrieb Graeme Geldenhuys:
> 
> Once again, read how the Git project deals with it. That workflow could suite 
> FPC quite well. 

You never developed a real world compiler and you have no real insight into fpc 
development so you
cannot know about this.

> In
> summary, feature are in separate branch. There is a public "testing stablish 
> changes" and a public
> "testing unstable" branches. Everything stays in branches until they are 
> signed off and merged into
> "master" (aka Trunk). Then less than 5 minutes is spend doing a "octopus 
> merge" of all branches that
> have been well tested and signed.

Who tests and signs? Our testing facilities cannot test more than a few (1, 2 
maybe 3) branches
nightly as we use build farms used also by other people. Further we test also 
on slow system, where
one run takes >1h. We have already >150 regression test runs per night with 
different parameters, on
difference architectures etc. This cannot be extended. Everything not in trunk 
(or master/) fixes is
not seriously tested and cannot seriously be tested, due to lacking resources. 
So feature branches
make only sense for big changes (as we do already with svn).

Or tests the "crowd" which makes OSS so powerful and everything is reviewed by 
dozens of people?
Looking at the problems FPC 3.0.2 has, people even didn't test release 
candidates seriously. And
some branch for a single feature? May I laugh?
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

2017-05-24 Thread Tomas Hajny

On Wed, May 24, 2017 16:51, Graeme Geldenhuys wrote:
> On 2017-05-24 15:30, Tomas Hajny wrote:
>> I have my doubts about availability of the GUI component for OS/2, but
>> you're welcome to prove me wrong. ;-)
>
> I haven't personally tried Git under OS/2, but I have two OS/2 VMs
> available, so I'll test.
>
> Does OS/2 have a port of TCL/TK? That's what those GUI's are written in.

I could find a port of Tcl/Tk version 8.3.5 on Hobbes. No idea if there
are newer ports somewhere else.

Tomas


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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Luca Olivetti


El 24/05/17 a les 16:03, Graeme Geldenhuys ha escrit:

On 2017-05-24 14:38, Luca Olivetti wrote:

$ LC_ALL=C git gui
git: 'gui' is not a git command. See 'git --help'.


I guess you can blame your Linux distro's rubbish package management 
requirement policies for that. They probably split Git into two or more 
packages. F**ken annoying if you ask me - hence I don't use Linux any more.


Right, unsurprisingly it's in the git-gui package.


bye
--
LUca

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Mark Morgan Lloyd


On 24/05/17 13:30, Graeme Geldenhuys wrote:

On 2017-05-24 12:46, Mark Morgan Lloyd wrote:>  >



could usefully be described as v1.4.1-787, and you can use that in>
conversation without having to be online to a repository.
Yes, you can use "v1.4.1-787" to describe a specific point in history,
but the far more common and useful one is the "45f932c1" SHA1 reference,
because the latter can be used directly in all Git commands.


If multiple people were committing directly to the same repository (I>
presume Git supports that)

Yes.

 presumably they'd see a consistent sequence> of version identifiers,
i.e. very much like Subversion.

Yes. A SHA1 reference like "45f932c1" only only points to a specific
commit, it also describes the history that lead to that point.



What happens in the case where there's multiple repositories?

No difference. A git repo contains the full history. If you clone that
repository 100 times between developers, you effectively have a 100
backups. If the original repo had 5 branches, all 100 clones with have
references (and full history) to those 5 branches too. Such remote
branch can be listed using the following command:
  git branch -r


Thanks very much for that, very interesting.

--
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 & SVN


On 2017-05-24 15:30, Tomas Hajny wrote:

I have my doubts about availability of the GUI component for OS/2, but
you're welcome to prove me wrong. ;-)


I haven't personally tried Git under OS/2, but I have two OS/2 VMs 
available, so I'll test.


Does OS/2 have a port of TCL/TK? That's what those GUI's are written in.

Regards,
  Graeme

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

Re: [fpc-other] Git & SVN


On 2017-05-24 15:32, Santiago A. wrote:

But IMHO it
clearly shows how poorly git defaults and parameters have been chosen.
And I am afraid that has been one of the hinders of git adoption.


The problem goes much deeper than that. I once brought up the issue of 
inconsistent command line parameters in the Git mailing list and gave 
ideas I thought were improvements.


They immediately confirmed the problem, and the problem in finding a 
solution. Some issues raised:


  * Because git has so many options (way more than normal apps), one
change can (and does) have affects on others.
  * Backwards compatibility. Changing the commands will break just about
every Git GUI front-end there is. Many of them simply parse the
output of a forked 'git' command. But they would actually consider
doing this for the greater good - I was impressed.
  * Conflicting command line parameter "modes".


If interested, the discussion can be found here:

   https://www.mail-archive.com/git@vger.kernel.org/msg76433.html


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 & SVN

2017-05-24 Thread Santiago A.

El 24/05/2017 a las 13:41, Graeme Geldenhuys escribió:
>
> Git has built-in support for alias. So you could simply define a
> couple of aliases in your $HOME/.gitconfig file that mimic the above
> commands, or even the SVN commands. I have over 20 aliases that I
> created over the years to simply long command line parameters.
>

> Now suddenly I can do this:
>
>   $ git switch develop
>

Maybe with Alias I don't need eg to redefine git CLI. But IMHO it
clearly shows how poorly git defaults and parameters have been chosen.
And I am afraid that has been one of the hinders of git adoption.

Here is an overview Easy Git (eg) parameters
https://people.gnome.org/~newren/eg/documentation/
I think it shows how git parameters should had been.


-- 
Saludos

Santiago A.

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Tomas Hajny

On Wed, May 24, 2017 16:03, Graeme Geldenhuys wrote:
> On 2017-05-24 14:38, Luca Olivetti wrote:
>> $ LC_ALL=C git gui
>> git: 'gui' is not a git command. See 'git --help'.
>
> I guess you can blame your Linux distro's rubbish package management
> requirement policies for that. They probably split Git into two or more
> packages. F**ken annoying if you ask me - hence I don't use Linux any
> more.
>
> I compile Git from the original source code, and it includes
> everything... Console, GUI and SubVersion support.

I have my doubts about availability of the GUI component for OS/2, but
you're welcome to prove me wrong. ;-)

Tomas


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

Re: [fpc-other] Git & SVN


On 2017-05-24 15:03, Graeme Geldenhuys wrote:

I compile Git from the original source code, and it includes
everything... Console, GUI and SubVersion support.


On this web page the first two screenshots are of gitk and git-gui - the 
standard GUI tools of Git.



https://git-scm.com/book/uz/v2/Git-in-Other-Environments-Graphical-Interfaces

They might not look as visually pleasing (eye-candy) as many other gui 
tools, but trust me, these built-in apps pack a punch (tons of 
features), and always supports git very well - obviously.



Regards,
  Graeme

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Luca Olivetti


El 24/05/17 a les 13:02, Graeme Geldenhuys ha escrit:

On 2017-05-24 01:26, nore...@z505.com wrote:

line much, but it serves my need very well visually committing which
files I need, which IMO is faster and more productive than running 5
different commands on files I have to manually type in or keep pressing


Git includes as standard all the GUI tools you would ever need. Plus 
those GUI tools are available on all platforms that Git supports. So 
there is no retraining in different tools for each platform. eg: 
Tortoise Git is only available on Windows. So if you jump to OSX or 
Linux or FreeBSD, you need to learn a different tool.


Or use mercurial with tortoisehg (note:when I switched from cvs to 
mercurial, git was not available for windows, while mercurial was 
already stable and multi-platform. I cannot claim I understand mercurial 
fully, but at least I can use it for basic tasks with no surprises, 
while my experience with git is like https://xkcd.com/1597/)





Anyway, the standard git GUI tools...

   * git gui:  visually make commits, do branch management, selective
 line-by-line commits, pull, push, merge etc.


$ LC_ALL=C git gui
git: 'gui' is not a git command. See 'git --help'.

Did you mean one of these?
gc
grep
init
pull
push

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

Re: [fpc-other] Git & SVN

On 2017-05-24 12:46, Mark Morgan Lloyd wrote:

 >   [reportdesigner (reportdesigner)]$ git describe
 >   v1.4.1-787-g45f932c1
 >
 > What does that output tell me:
 >   * Whatever code I'm working on is follow on from the "v1.4.1"
 > release.
 >   * This line of [development] history has seen "787" commits
 > since the v1.4.1 release.

says explicitly that the modification with the hash g45f932c1 takes the
project on the Git repository under consideration to something that
could usefully be described as v1.4.1-787, and you can use that in
conversation without having to be online to a repository.

Yes, you can use "v1.4.1-787" to describe a specific point in history, 
but the far more common and useful one is the "45f932c1" SHA1 reference, 
because the latter can be used directly in all Git commands.

If multiple people were committing directly to the same repository (I
presume Git supports that)

Yes.

 presumably they'd see a consistent sequence
of version identifiers, i.e. very much like Subversion.

Yes. A SHA1 reference like "45f932c1" only only points to a specific 
commit, it also describes the history that lead to that point.

Let me explain: Say you have two branches with the same file, and the 
file hasn't actually changed between those two branches. Now say I give 
you a patch file to apply to that file in both branches. The commits 
that gets generated in each branch - even though the diff is identical - 
will not have the same SHA1 reference. Because the history to get to 
that point has diverged because of the branching.

So if I mention a problem in the "45f932c1" commit of a Git repository. 
No matter how many clones [by multiple developers] there are of that 
repository, that SHA1 reference will point to the exact commit and code 
change - in all the Git repositories out there in the wild.

This is also one of the huge arguments about NOT using the git-rebase 
command on a branch that has been published, because a rebase command 
rewrites the history. So every commit (SHA1 reference) in that affected 
branch changes. Rebasing local branches (not made public yet) is 
obviously not a problem.

The Git project repo has a "short lived" branch where they do all kinds 
of testing. They explicitly note that nobody should base any new 
development on that branch, because it will frequently be destroyed and 
recreated (merging in new feature to be tested for the next cycle).

What happens in the case where there's multiple repositories?

No difference. A git repo contains the full history. If you clone that 
repository 100 times between developers, you effectively have a 100 
backups. If the original repo had 5 branches, all 100 clones with have 
references (and full history) to those 5 branches too. Such remote 
branch can be listed using the following command:

  git branch -r

eg:

[tiopf (tiopf2)]$ git branch -r
  carlo_marona/Add_tiLogToDebugString
  carlo_marona/Additional_Mediators
  carlo_marona/Fix_BOOLEAN_Defines
  carlo_marona/Fix_TtiDatabaseZeosAbs_SetConnected_Except
  carlo_marona/Fix_tiCriteria_AssignClassProps
  carlo_marona/Fix_tiMediatorView
  carlo_marona/Fix_tiModelMediator
  carlo_marona/Fix_tiQueryZeosIBFB_Unit
  carlo_marona/tiOIDManager_Update
  carlo_marona/tiopf3
  github/master
  github/tiopf1
  github/tiopf2
  github/tiopf3
  sourceforge/HEAD -> sourceforge/master
  sourceforge/fea_Fix_Event_Execution_Of_TtiPropertyLinkDef
  sourceforge/fea_Missed_Changes_On_tiOPF3
  sourceforge/master
  sourceforge/tiopf1
  sourceforge/tiopf2
  sourceforge/tiopf3

Here you can see my local tiOPF repository has 3 remote repositories 
defined. "carlo_marona", "github" and "sourceforge". I frequently pull 
fixes from Carlo, so that is why I have a permanent remote repository 
link to his published work. For contributions from one-off developers I 
don't bother setting up a remote repository link - I use their 
repository URL directly in the git-fetch command.

The official public tiOPF repository lives on SourceForge.net, so that 
is the "sourceforge" remote repo link. The "github" link was just a 
backup public repo I used while SourceForge.net had a major global 
outage a little while ago. So development continued as usage without 
skipping a beat (thanks Git).

You can also see from Carlo's repository that he nicely names each 
branch, and every branch that is a bug fix has the prefix name "Fix_" to 
it. In the end you can name branches whatever you want though, and you 
can even groups things with a "/" in the name of the branch.

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 & SVN


On 2017-05-24 12:49, Mark Morgan Lloyd wrote:

s the licensing problem (Sun's license being
incompatible with GPL) which resulted in a lot of FUD.


It's only a problem if you want it to be. Yes, they can't include ZFS as 
standard with a Linux Distro (though some now apparently do), it is is 
pretty much a two command step to get it installed.


  1)  // Add the add-on apt repository to your list
  2) apt-get install zfs

Something like that - its been a while since I did that in my dual-boot 
Linux environment. Also ZFS doesn't run via FUSE on Linux any more - it 
is a "native" file system now.


  https://launchpad.net/~zfs-native/+archive/ubuntu/stable
  http://zfsonlinux.org/

The really good news is that for some time now, all ZFS development is 
merged into a single organization. So OSX, Linux, FreeBSD all have the 
same ZFS features and functionality. No more fragmented development.


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 & SVN

2017-05-24 Thread Karoly Balogh (Charlie/SGR)

Hi,

On Wed, 24 May 2017, Graeme Geldenhuys wrote:

> If the Free Pascal team is ever serious about migrating to Git, I'll
> happily help out with the migration process.

Well, I think the resistance is too big for the migration. The SVN people
go full berserk bloodbath mode when Git is mentioned, and Git people
usually go "whatever" and just use git-svn. :)

But. If we could come up with a way, which allows accepting pull requests
with Git somehow (thinking about Github, specifically, but in general),
then have them seamlessly integrated into upstream SVN as they're
accepted, that would maybe move things forward. (Remember, we even have an
FPC organization on Github, which we can utilize.)

With the more automated verifications regarding the integrity of the SVN
the better. But Marco was right on the point, that this needs a very very
carefully designed plan and process, to not screw up the upstream SVN.
Maybe what LLVM and GCC has in place can serve as a starting point.

And to be honest, I wouldn't even have the full SVN mirror "published" in
Git, only trunk, and branches fixes_3_0 and newer, with the later being
read only, as merges would happen by the maintainer, in SVN.

So yeah, TL;DR: instead of trying to fix people we could use engineering
to make the technology just serve us all. :)

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Mark Morgan Lloyd

On 23/05/17 14:10, Mark Morgan Lloyd wrote:

One question if I may. Subversion has revision numbers like 12345, and
it's comparatively easy to query that and build it into a piece of
software's version information. It's also trivial for a developer to
look at the revision that he's currently working with, to say whether
it's older or newer than revision 12345, and to get a log of what the
relative changes were by /only/ knowing the revision number.
Now I don't deny for a moment that Git has its advantages for
distributed working. But am I correct in my understanding that it has
nothing that maps directly onto the monotonic revision list of
traditional VCSs including Subversion?

Apologies for the poor threading, but not all ML messages get through 
our gateway.

Thanks for the explanation Graeme, I hope that I'm not the only person 
here to find that instructive. So in the context of what I asked

>   [reportdesigner (reportdesigner)]$ git describe
>   v1.4.1-787-g45f932c1
>
> What does that output tell me:
>   * Whatever code I'm working on is follow on from the "v1.4.1"
> release.
>   * This line of [development] history has seen "787" commits
> since the v1.4.1 release.

says explicitly that the modification with the hash g45f932c1 takes the 
project on the Git repository under consideration to something that 
could usefully be described as v1.4.1-787, and you can use that in 
conversation without having to be online to a repository.

If multiple people were committing directly to the same repository (I 
presume Git supports that)  presumably they'd see a consistent sequence 
of version identifiers, i.e. very much like Subversion.

What happens in the case where there's multiple repositories? How 
brutally would each one have to be whacked before it was guaranteed that 
every one had the same correspondence of release-commit tuples and 
hashes? Could this be /forced/ at the project level and what 
implications would that have on the amount of data transferred to 
synchronise them?

--
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 & SVN

2017-05-24 Thread Mark Morgan Lloyd


On 24/05/17 08:30, Graeme Geldenhuys wrote:


Sorry, I've just had too many hard drives fail on me... so many fail>
that it's almost as if someone was doing it on purpose to me.

Sounds like you are in serious need of ZFS. If you work on a laptop (so
can't install 3+ hard drives), then I recommend you get one of those
USB3 or Thunderbolt port external NAT-style storage devices. I know some
of them support ZFS. But those storage devices are a bit costly. But
then, how much is your data worth?


I agree, it's really very good indeed and I think the only reason that 
it's not more widely used is the licensing problem (Sun's license being 
incompatible with GPL) which resulted in a lot of FUD.


--
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 & SVN


On 2017-05-24 12:32, Karoly Balogh (Charlie/SGR) wrote:

missing from the converted repo, at least the one the FPC Team had
internally. As in, the history wasn't complete. Not sure what that means


The bottom line is, the end result should be identical to what you see 
when you do a 'svn co' on any branch, compared to the Git migrated 
version. At least this was my case in all the conversions I have done.


Some of the git-svn output is weird though. They sounds more alarming 
than they really are. eg: If you had a commit that only changes svn 
properties, I believe sometimes git can skip over such commits because 
there is no direct translation to Git. But those are generally rare, and 
often not an issue, because it was more SVN repo maintenance that 
actually tracking changes to files. The latter being way more important.


If the Free Pascal team is ever serious about migrating to Git, I'll 
happily help out with the migration process.


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 & SVN


On 2017-05-24 08:21, Santiago A. wrote:

i.e. instead of

git checkout master
git checkout develop

eg switch master
eg switch develop


Git has built-in support for alias. So you could simply define a couple 
of aliases in your $HOME/.gitconfig file that mimic the above commands, 
or even the SVN commands. I have over 20 aliases that I created over the 
years to simply long command line parameters.


For example:

  $ git config --global alias.switch checkout

will result in the following

-[ ~/.gitconfig ]-
[alias]
   st = status -uno
   svnlog = log --stat=70 --pretty=medium --name-status --reverse
   ...snip...
   switch = checkout

--


Now suddenly I can do this:

  $ git switch develop


No need for Perl add-ons. ;-)

ps:
  Above I listed two of my most used aliases as well. I have plenty of
  others too.




  git checkout master
  git merge feature1 feature2 feature3 feature4 feature5

...where "featureX" is a branch name.


Yes, that's very handy... and scaring.
The merge is done magically in the repository, not in a working machine,


Everything is done locally first. So if you are not happy with the 
result, it can be undone with a simple git-reset command.




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 & SVN

2017-05-24 Thread Karoly Balogh (Charlie/SGR)

Hi,

On Wed, 24 May 2017, Graeme Geldenhuys wrote:

> Back in 2009 (I think it was) when I created Git mirrors of FPC and
> Lazarus, I initially did it with all branches and tags in place. It took
> long, but there was no roadblocks.

I think the claim was, after the svn 2 git conversion, some commits were
missing from the converted repo, at least the one the FPC Team had
internally. As in, the history wasn't complete. Not sure what that means
though, or which commits, commits of which nature, or why. Maybe Florian
can ellaborate on this.

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

Re: [fpc-other] Git & SVN


On 2017-05-23 19:37, Florian Klämpfl wrote:

First problem: quote from core:


The git-to-svn bridge is slow, but pretty good - not perfect, sometimes 
it falls over and needs a restart. But I can honestly say, I have 
converted full SubVersion repositories (from small to very large) to 
Git, and always managed to have everything in Git at the end.


Nobody ever stated that any type of migration is going to be without 
problems. It's the nature of migration. I've stated numerous times that 
SubVersion is often abused because they have very bad concepts, which 
have been clearly designed and developed in Git. "Tags" are the first 
thing that comes to mind.


Back in 2009 (I think it was) when I created Git mirrors of FPC and 
Lazarus, I initially did it with all branches and tags in place. It took 
long, but there was no roadblocks. The only reason I then changed it to 
only track the "trunk" branches is because I personally think a 
migration should be a one-shot deal, not a continuous process. It was a 
pain to manually update and work around the weird SubVersion behaviours 
(commits after a Tag was created - God Damn, use a branch instead!).


Over the years I've personally migrated over 200 SubVersion repositories 
to Git. My final step has always been to checkout each SVN repository 
and branch, and then do a checksum comparison to the Git version. 
Ensuring everything is like it is supposed to be. Any discrepancies can 
then be resolved with a single commit, but to be honest, I can't recall 
ever having the need to do that.


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 & SVN

2017-05-24 Thread Santiago A.

El 24/05/2017 a las 8:57, Graeme Geldenhuys escribió:

My company uses svn and I use git for my local work since Mr Geldenhuys
praised it a year or two ago ;-). For me, branching is the really the
big thing. I have several branches running, and I only commit to svn
repository after testing everything.

Git is complicated, I don't mean it is overcomplicated, just it's more
complicated than svn because it tries to accomplish more and more
complicated tasks than svn. In fact, the discuss shouldn't be svn vs
git, but centralized version control vs distributed version control.
Nevertheless, git has a complicated and anti-intuitive command line
syntax. Git is the winner over others, like Mercurial, because of Linus
Torvald's popularity, not that Git is better or worse than Mercurial,
just that their technical virtues had little to do with the success of
git.  I use Easy Git, It is a perl script that In the background it
calls git, but syntax is more sensible.

i.e. instead of

git checkout master
git checkout develop

eg switch master
eg switch develop



>
>   git checkout master
>   git merge feature1 feature2 feature3 feature4 feature5
>
> ...where "featureX" is a branch name.

Yes, that's very handy... and scaring.
The merge is done magically in the repository, not in a working machine,
It is a little black box. But it's looks that it manages to do its job.
Nevertheless I have had some unexpected issues... it is scaring. :-P

Should I recommend git for central repository in my company? Not sure.
What's the difference between pulling from several repositories and
pushing to a central repository? In the end, I prefer the central
repository with a more lineal history. I think that distributed
development works better when there is a big project with independent
parts. For me, in Git is much important de advantage of easy local
branches that distributed development.

On the other hand, probably I'm getting old ;-) :-(

-- 
Saludos

Santiago A.

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

Re: [fpc-other] Git & SVN


On 2017-05-24 02:11, nore...@z505.com wrote:

I'd rather upload/commit files to a server to insure it is backed up
properly...


There is absolutely no guarantee that your file are any safer. So you 
have your Army of Developers in a single building. You store all your 
files on a Server which is in the server room in the basement of the 
building behind steel doors. Oh wait, a Boeing 747 fully fuelled just 
flew into your building. Everything is now a pile of rubble. Oh the 
backups where on another server next to the one you pushed changes to.


;-)

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 & SVN


On 2017-05-24 01:26, nore...@z505.com wrote:

line much, but it serves my need very well visually committing which
files I need, which IMO is faster and more productive than running 5
different commands on files I have to manually type in or keep pressing


Git includes as standard all the GUI tools you would ever need. Plus 
those GUI tools are available on all platforms that Git supports. So 
there is no retraining in different tools for each platform. eg: 
Tortoise Git is only available on Windows. So if you jump to OSX or 
Linux or FreeBSD, you need to learn a different tool.


Anyway, the standard git GUI tools...

  * git gui:  visually make commits, do branch management, selective
line-by-line commits, pull, push, merge etc.

  * gitk: visually see your commit history. For a specific branch, or
 all branches in the repo. You can also cherry-pick commits from
 one branch into another.

  * gitk --  See the full history for a specific file only, or
for a directory only.

  * git gui blame: visually see line-by-line who made which changes.

All these gui tools also have built-in navigation, where if you click on 
a SHA1 it navigates to it.





The point is that github does in fact allow you to treat a github repo
like an SVN one,


Ah, I see that now. I never knew that existed. It is definitely a Github 
only thing.



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 & SVN

2017-05-24 Thread Marco van de Voort

In our previous episode, nore...@z505.com said:
> >> impossible person is usually swiftly dealt with.
> 
> > 
> > Honestly, I can't even... You sound like the Expert Beginner Twitter
> > account. No personal offense intended, but you just do.
> > 
> 
> He's talking about Army of Programmers in a Building, an article I wrote 
> years ago ;-)
> 
> Sometimes it's better to just walk over and talk to a real programmer in 
> a real building than it is to send some email over the christmas 
> holidays and wait 2 weeks for a reply for him to commit his changes.. 
> since he's in Barbados or Cuba on vacation.

The scenario was based on older commercial VCS systems (VSS, that Team thing
from Borland etc etc) that required explicit locking, and people would lock
files, change some formatting and then go on holiday before their real work
started.  During that time nobody could make changes to those files, and
even back then we already had some form of CI to a testserver that worked
from the VCS, so that also hampered testing your own mods.

Locks were notorious hard to break, and persons with the required
rights were often also rare during those periods.

And yes, if you did that, specially if the file was something central (like
a file that listed all commands accepted by the command processor), people
could get somewhat aggressive ;-)

The DVCS scenario is not as bad, but some simple prevention of this would
prevent some mistakes, and make the minefield for new devels a bit smaller,
thus save a lot of annoyance on all sides.

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

Re: [fpc-other] Git & SVN


On 2017-05-24 02:46, nore...@z505.com wrote:

But what happens with corrupted or failed hard drive on your personal
computer? Do you have any backups or is this local git work only on one


I used to live in a country with constant blackouts or brownouts. So 
harddrives took a real punishment. UPS's were a requirement, not a 
luxury. So I take data protection very seriously, even though where I 
live now the power is much more reliable and clean.


Yes, I have off-site private backups, and on occasion I push those to a 
USB stick too. Everybody should at least be doing this.


I also know how valuable my work and data is - I run my own business. 
All my data, code and VMs lives on 4 server quality harddisks using ZFS 
RAID-Z2 as the file system, and FreeBSD as my OS of choice. I will not 
trust my data on anything other than ZFS. Even my USB sticks use ZFS. My 
hard drives were bought from different suppliers so they aren't all from 
the same batch. I also replace them every 3-4 years (ZFS makes this a no 
brainer).


I highly recommend you read up on ZFS if you don't know it. It comes 
natively with Solaris and FreeBSD, and is easily installed on Linux. I 
believe OSX might also have unofficial support now.


ZFS is a copy-on-write files system. Every read and write is 
checksummed. I can have two hard drives fail (very very unlikely) and 
still be able to rebuild my data. Very sensitive data I store in a 
partition that keeps two copies of the data scattered around the ZFS 
pool. ZFS partitions can be created and destroyed on the fly - they are 
more like directories than partitions. So you can create and destroy 
partitions as the need arises, and set encryption, compression, 
de-duplication etc on each partition as you see fit.




Sorry, I've just had too many hard drives fail on me... so many fail
that it's almost as if someone was doing it on purpose to me.


Sounds like you are in serious need of ZFS. If you work on a laptop (so 
can't install 3+ hard drives), then I recommend you get one of those 
USB3 or Thunderbolt port external NAT-style storage devices. I know some 
of them support ZFS. But those storage devices are a bit costly. But 
then, how much is your data worth?




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 & SVN


On 2017-05-23 21:41, Florian Klämpfl wrote:

This is what I do as well for several things, but I still think, subversion is 
the better solution
as the canonical FPC repository.


The ‘git-svn’ functionality is great - I use it for several SubVersion 
projects too. It also unfortunately stops you from using many of the 
nicer features of Git. So you definitely don’t get the full experience - 
it’s more like the “cheap seats” at a concert. You can say you were 
there and heard the band sing, but you couldn’t actually see them.


Regards,
  Graeme

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

Re: [fpc-other] Git & SVN


On 2017-05-24 02:01, nore...@z505.com wrote:

I like the ability to fork, as I am sick of developers not allowing me
to make some change, and I go off and work myself on some fork but..
it's also anti-social and leaves projects in so many forks that no one


"fork" is probably the wrong word. I prefer the word "clone" instead. It 
is only anti-social if YOU (the developer) don't share your changes. You 
do that by sending a pull request to the original project.


See...

  git help request-pull

...for more details. And no, you don't require GitHub for pull requests, 
it's built right into Git.



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 & SVN


On 2017-05-23 21:19, Marco van de Voort wrote:

I was not asking for ideally. I was asking very specifically how a GIT in a
FPC team group would work.

And no, sending 40+ pull requests to all members of core does not count. So
there is one golden repo and that is what I'm talking about.


And like I explicitly said, read the well documented processes followed 
by the Linux Kernel or on a much smaller scale, the Git development itself.




I would like to have lots of extra manpower too, but I rather not spend it
on what in practice would be rubberstamping commits (and delays in
distribution till something is approved if the reviewers are AFK).


Once again, read how the Git project deals with it. That workflow could 
suite FPC quite well. In summary, feature are in separate branch. There 
is a public "testing stablish changes" and a public "testing unstable" 
branches. Everything stays in branches until they are signed off and 
merged into "master" (aka Trunk). Then less than 5 minutes is spend 
doing a "octopus merge" of all branches that have been well tested and 
signed.


If you don't know, a octopus merge is a single merge command but merges 
2+ branches all in one go. eg:


  git checkout master
  git merge feature1 feature2 feature3 feature4 feature5

...where "featureX" is a branch name.

Unlike SubVersion, you don't waste a whole day "rubber stamping" 
commits. Such micro-management doesn't exist in Git. Git was designed to 
work better that SubVersion, and specificall at branch management and 
merging.


Hence my earlier WTF comment when I read the LLVM team want- to ban 
merge commits! That person clearly has no f**ken idea how Git works.




In distributed, volunteer driven, projects, people are away/nonresponsive for
extended periods of time, working hours (and days) don't match. Also working
this out via mail is much less productive.


Then simply don't pull or merge their work. Simple as that. Once again, 
you are thinking in terms of SubVersion. Don't!


You don't see the Linux Kernel project come to halt when somebody fucks 
up a commit - they just don't merge that commit or branch until the 
idiot fixed his work. And neither do they have communications problems 
via emails or the mailing list - they have tens of thousands of 
contributors spanning the globe. So I don't understand why you think 
such a small project like FPC will have communication issues. That's 
just laughable.




Sorry to say, but I didn't find anything new or usable in this post.


Actually, it's only your stubbornness showing. I thought Karoly's reply 
was very informative.




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 & SVN


On 2017-05-23 17:41, Graeme Geldenhuys wrote:

On 2017-05-23 21:16, Florian Klämpfl wrote:

... and the code is lost :)


Not at all, I have about 20+ local branches in my fpGUI repository.
Some branches date back to 2009, 2010. Ideas I had, but lost
motivation, or they were simply an experiment (that could be useful at
some point). Just 2 days ago I revived a 5 year old branch and finally
completed the work.


But what happens with corrupted or failed hard drive on your personal 
computer? Do you have any backups or is this local git work only on one 
personal hard drive that could fail at any time?



Sorry, I've just had too many hard drives fail on me... so many fail 
that it's almost as if someone was doing it on purpose to me.


Do you make some backups on a usb stick or some server elsewhere no one 
can see?

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

Re: [fpc-other] Git & SVN

On 2017-05-23 15:36, Karoly Balogh (Charlie/SGR) wrote:

> At work, I don't even push against master, but I do a pull request
> against my own repository, and ask one of my senior colleagues to
> review... I don't know about you, but to me this sounds a lot more
> like teamwork, than going around beating up people "for wrongdoing"
> with a cluestick.

Then you don't understand what I mean. In the job you go see the 
person,

work something out, and problem sorted in a few minutes. The odd
impossible person is usually swiftly dealt with.

Honestly, I can't even... You sound like the Expert Beginner Twitter
account. No personal offense intended, but you just do.

He's talking about Army of Programmers in a Building, an article I wrote 
years ago ;-)

Sometimes it's better to just walk over and talk to a real programmer in 
a real building than it is to send some email over the christmas 
holidays and wait 2 weeks for a reply for him to commit his changes.. 
since he's in Barbados or Cuba on vacation.

With Army of Programmers in a Building you can just go and knock on his 
door, or his cubicle, instead of this pathetic thing called Email.

The disadvantage of working in the same town/building as someone, 
though, is that they may always be bothering you non stop and tapping on 
your shoulder, but not really since programmers aren't that obnoxious, 
AFAIK

This development on the internet across multiple countries has some 
massive disadvantages to something like the Microsoft Campus where you 
can go over and knock on the guys door, or at Borland (although, they 
are hiring people offshore AFAIK now)

And sometimes typing out a long email takes time, instead of just being 
able to speak in real time to a real person - an email is like a fixed 
essay, whereas a conversation is in real time, instant. They have IRC 
for this, I guess, but that becomes addictive and wastes lots of time, 
IMO, and you don't get as much work done if you are chit chatting 
nonstop on irc/icq/message systems

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

Re: [fpc-other] Git & SVN


On 2017-05-23 17:33, Graeme Geldenhuys wrote:

On 2017-05-23 21:10, Karoly Balogh (Charlie/SGR) wrote:

Now, in Git, this idiot can do:


Plus that idiot could start the fork and his branch without needing to
bother the FPC team. With SVN he has to ask them to add him to the
SubVersion repo user list, create a branch, and manage his user
permissions for that branch.



Yes but forking is a double edged fork (sword)...
You can fork so easily that no one actually works together and then you 
have 218982 versons of emacs floating about that no one actually uses, 
because so many forks splits up the userbase and then everyone just ends 
up using a central version of emacs, the main copy



Git = KISS is this case. ;-)



Everyone making thousands of forks and not working together is not 
simpler, it's just a different way


I like the ability to fork, as I am sick of developers not allowing me 
to make some change, and I go off and work myself on some fork but.. 
it's also anti-social and leaves projects in so many forks that no one 
works together. Everyone forks github repos and then you cannot search 
the damn code on github, as forks are not searchable - so no one can 
find good updated code, you just see the main git repo, which, is kind 
of like having a central svn repo! but with thousands of stale forks???

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

Re: [fpc-other] Git & SVN


On 2017-05-23 09:01, DaWorm wrote:

emacs!  vi!

Let's call the whole thing off and use EDLIN.


Don't forget mg

https://www.google.ca/search?q=mg+micro+gnu+emacs

From what I remember, this one had some nice simple C source code 
instead of bloated projects..

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

Re: [fpc-other] Git & SVN


On 2017-05-23 04:23, Graeme Geldenhuys wrote:

On 2017-05-22 23:11, nore...@z505.com wrote:

What happens if you use the SVN bridge that allows you to run svn
commands to a git server?


Maybe your wording is confusing, or SVN has abilities I didn't know
of.


it may just be a github thing, I'm not sure. Not git, possibly, but 
github has an SVN bridge that allows you to treat a github repo just 
like an SVN repo, and run svn commands.
I use total commander for most of my SVN work with tortoise svn, which 
sounds like I am some kind of newbie/beginner since I don't use command 
line much, but it serves my need very well visually committing which 
files I need, which IMO is faster and more productive than running 5 
different commands on files I have to manually type in or keep pressing 
the up arrow to repeat old commands (seems like 1970's way of doing 
things on unix, which I avoid) But I guess that is another issue.


The point is that github does in fact allow you to treat a github repo 
like an SVN one, so I wondered if Florian had tried this - but I guess 
you might as well use SVN if you are going to make github "like svn" 
instead of actually being svn. Key advantage: use github awesome web 
interface gui, plus have svn like revision...


IMO the big success of git is not git, but the github website which is 
visually stunning, beautiful, and productive - along with being a great 
social tool (although, I'm not so social). Only gripe I have about 
github is the fact that you cannot search forks! Searching forks on 
their website is essential for finding other people's code, and you 
cannot do that. you can't search any forks??? wtf..

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

Re: [fpc-other] Git & SVN


On 2017-05-23 04:23, Graeme Geldenhuys wrote:

On 2017-05-22 23:11, nore...@z505.com wrote:

What happens if you use the SVN bridge that allows you to run svn
commands to a git server?


Maybe your wording is confusing, or SVN has abilities I didn't know
of. I know Git can manage SVN repositories, but I didn't know it was
possible other way round (I doubt it is possible).


I use it every day.

When I hired someone for a bounty, he introduced me to it, and I have 
been using it ever since :-)

p.s. Thanks Dmitry! ;)

It's my stubborn old practice of not wanting to learn a new tool, Git, 
when SVN was working quite fine for my needs, but I do admit I don't 
have experience working with thousands/hundreds of developers all on the 
same repo, I more use it for my own need.

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

Re: [fpc-other] Git & SVN


On 2017-05-23 21:16, Florian Klämpfl wrote:

... and the code is lost :)


Not at all, I have about 20+ local branches in my fpGUI repository. Some 
branches date back to 2009, 2010. Ideas I had, but lost motivation, or 
they were simply an experiment (that could be useful at some point). 
Just 2 days ago I revived a 5 year old branch and finally completed the 
work.


I didn't pollute the public fpGUI repos because it was personal ideas or 
features I toyed with. They are in various incomplete stages, or simply 
experiments. I don't want others to see such work until my ideas have 
matured.


On the flip side, in the past I have seen newsgroup posts where somebody 
has similar ideas to one or two of my incomplete branches. In such cases 
I speak to that person and if interested, I publish such a branch to 
begin collaboration.


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 & SVN


On 2017-05-23 21:05, Florian Klämpfl wrote:

FPC is a compiler and not an OS kernel, so would like to see such
blog posts from big compilers: e.g. gcc, clang


OS Kernel, Compiler, any other project - what's the difference. Git 
development itself is managed in a very "distributed" way with multiple 
branches, maintenance releases etc. And more impressively, all branch 
merging is done by a single person. Their processes are quite well 
documented, and if you see how active the Git development is, it goes a 
long way proving that even a very active project can be managed by very 
few (one in this case).


My point is, you can learn from them to see how a project can be managed 
without adding extra work-load to one person or a small team (like FPC).


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 & SVN

Hi,

On Tue, 23 May 2017, Florian Kl?mpfl wrote:

> > so they just use git-svn.
>
> This is what I do as well for several things, but I still think,
> subversion is the better solution as the canonical FPC repository.

*shrug*

As I said, I'm fine with it anyway, whatever. But I can see the practical
reasons for Git, and see the reason why people would want it. And I came a
*lng* way to admit that. In late-2009 early-2010 I sounded more
anti-Git than Marco. :)

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

Re: [fpc-other] Git & SVN

Am 23.05.2017 um 22:36 schrieb Karoly Balogh (Charlie/SGR):
> so they just use
> git-svn.

This is what I do as well for several things, but I still think, subversion is 
the better solution
as the canonical FPC repository.
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

Hi,

On Tue, 23 May 2017, Marco van de Voort wrote:

> Trust is that people are not deliberately doing things. For accidental
> things there are tools (except GIT, apparently)

Err...? :) The only way to can fuck up a remote Git repository is by force
pushing, if you have write access already. But you can disable force
pushing even for people with write access. (Which is advisable.)

> I was not asking for ideally. I was asking very specifically how a GIT in a
> FPC team group would work.

See my other mail.

> > At work, I don't even push against master, but I do a pull request
> > against my own repository, and ask one of my senior colleagues to
> > review... I don't know about you, but to me this sounds a lot more
> > like teamwork, than going around beating up people "for wrongdoing"
> > with a cluestick.
>
> Then you don't understand what I mean. In the job you go see the person,
> work something out, and problem sorted in a few minutes. The odd
> impossible person is usually swiftly dealt with.

Honestly, I can't even... You sound like the Expert Beginner Twitter
account. No personal offense intended, but you just do.

> In distributed, volunteer driven, projects, people are away/nonresponsive for
> extended periods of time, working hours (and days) don't match. Also working
> this out via mail is much less productive.

So it's much more productive to just give everyone commit access to the
main repo, and let it being polluted with random branches? Or anyone who
wants to contribute but not with FPC for years, should keep working on his
working copy (with no ways to commit) and then submit a .diff via Mantis?

(Well, people are smarter than that, fortunately, so they just use
git-svn. Whatever.)

> Sorry to say, but I didn't find anything new or usable in this post. It is
> the standard "think different" nonsense from a very idealist viewpoint,
> little practical details.

Err, see my other mail about a practical example.

> So I now give up this thread (and GIT).

You should try to use it. For once. With an open mind. I know it's hard.

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

Re: [fpc-other] Git & SVN

Hi,

On Tue, 23 May 2017, Florian Kl?mpfl wrote:

> > For those interested, read the many blobs about how the Linux Kernel
> > development is managed.
>
> FPC is a compiler and not an OS kernel, so would like to see such blog
> posts from big compilers: e.g. gcc, clang

I see your point Florian, but at least LLVM seems to have a Git gateway
these days, and they documented how to contribute using Git, while they
can keep their upstream SVN.

http://llvm.org/docs/GettingStarted.html#sending-patches-with-git

And the same with GCC:

https://gcc.gnu.org/wiki/GitMirror

The important fact to see is Git allows people do their own branches
(local branches, of course) and forks much easier/cheaper in a way, which
also makes easier to contribute their changes back to the main project
they originally forked. This part is at least is independent from the
nature of the software developed, and the poIitics involved, I think.

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

Re: [fpc-other] Git & SVN

In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > how to avoid that a push of member X doesn't leave a branch in an
> > undesirable state that leaves member Y three choices:
> 
> How to avoid that member X with commit write access doesn't leave a branch
> in SVN in an undesirable state? :) You have to trust people, and choose
> who you give write access to a given branch/repository, really. This
> didn't really change and not an argument against git.

Trust is that people are not deliberately doing things. For accidental
things there are tools (except GIT, apparently)
 
> And well, in Git you don't push, but people who want to contribute, have a
> pull request. Then you can review that, and either apply to your tree or
> reject it. It's important to understand that in git all repositories are
> equal, and that I have a "make-amiga-great-again" branch, doesn't mean
> that you should have it, I could still send a pull request against your
> master branch, or whatever branch. All pull requests are just a set of
> changes, really.

Yeah, blabla, distributed, anarchy, world domination. I though I did mention
I wanted practical info?

> > 1. push anyway and make the mess worse
> > 2. hold the commit/push
> > 3. clean the mess himself.
> 
> Well, ideally 

I was not asking for ideally. I was asking very specifically how a GIT in a
FPC team group would work.

And no, sending 40+ pull requests to all members of core does not count. So
there is one golden repo and that is what I'm talking about.

> easily. It's the responsibility of the maintainer of a given branch to
> accept that pull request or not, or request further changes before its
> accepted.

So tool failure is fixed by throwing manpower at it?

We don't have an approval person now, so a requirement to that would IMHO be
a dealbreaker for GIT.

> And talking about myself - as much as I enjoy just committing my crap to
> trunk, I sometimes would really prefer review. Not because I'm not a
> senior engineer, but especially because of that... Now if I don't want to
> do a branch in SVN which are huge and expensive (Git branches are cheap
> and small), I either have to commit it first anyway to trunk, then ask for
> a review, or send a patch for review first in e-mail, which is quite
> cumbersome. Plus there's absolutely no warranty, that I later commit the
> same patch which was reviewed.

I would like to have lots of extra manpower too, but I rather not spend it
on what in practice would be rubberstamping commits (and delays in 
distribution till something is approved if the reviewers are AFK). 

This is exactly what I wanted to avoid with the primary case posed in this
subthread: how to avoid blocking the central repo for commits (from a
practical viewpoint)
 
> At work, I don't even push against master, but I do a pull request against
> my own repository, and ask one of my senior colleagues to review... I
> don't know about you, but to me this sounds a lot more like teamwork, than
> going around beating up people "for wrongdoing" with a cluestick.

Then you don't understand what I mean. In the job you go see the person,
work something out, and problem sorted in a few minutes. The odd impossible
person is usually swiftly dealt with.

In distributed, volunteer driven, projects, people are away/nonresponsive for
extended periods of time, working hours (and days) don't match. Also working
this out via mail is much less productive.

> Of course in the end it's just like crypto - you need to have a chain of
> trust from the top, a group of trustees who will do the actual merging of
> the pull requests, reviews and then push it upstream/mainline/trunk. If
> one of these maintainers do a bad job, then you need to sort out that
> problem, but that doesn't mean the whole system is broken. It's similar to
> giving commit access to a developer who doesn't deserve it in SVN, really.

I know what an honor-system is. It doesn't protect against mistakes the day
before holiday. Remember the old locking VCSes ?

> Now, how the actual process would look with the FPC team, that's hard to
> define at this point. But the tools are there for it.
> 
> Was this a proper answer, or I was beating around the bush in your views?
> :)

Sorry to say, but I didn't find anything new or usable in this post. It is
the standard "think different" nonsense from a very idealist viewpoint,
little practical details.

So I now give up this thread (and GIT).
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

Am 23.05.2017 um 22:10 schrieb Karoly Balogh (Charlie/SGR):
> 
> 1., Have his own clone of the FPC repository. Create his local webassembly
> branch, and keep happily working on his local copy, then leave it rot
> when he loses motivation, doesn't distract anyone.
> 

... and the code is lost :)
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

Hi,

On Tue, 23 May 2017, Karoly Balogh (Charlie/SGR) wrote:

> > To get get back on track, I'll restate the question I posed in the last
> > message unambigously:
> >
> > how to avoid that a push of member X doesn't leave a branch in an
> > undesirable state that leaves member Y three choices:
>
> How to avoid that member X with commit write access doesn't leave a branch
> in SVN in an undesirable state? :) You have to trust people, and choose
> who you give write access to a given branch/repository, really. This
> didn't really change and not an argument against git.
>
> And well, in Git you don't push, but people who want to contribute, have a
> pull request. Then you can review that, and either apply to your tree or
> reject it. It's important to understand that in git all repositories are
> equal, and that I have a "make-amiga-great-again" branch, doesn't mean
> that you should have it, I could still send a pull request against your
> master branch, or whatever branch. All pull requests are just a set of
> changes, really.

Ok, to put this into practical example: lets say some idiot decides to do
a Webassembly codegenerator for FPC. This idiot starts working on his
working copy, but quickly loses track... So he wants to start committing
his changes. But in SVN, this idiot has to either:

A., create a Webassembly branch and start committing there, polluting the
global SVN repository forever, even if he's demotivated after 5 commits,
and never touches that branch again. (...)

B., keep his changes in his working copy forever, getting in the way of
other changes, and causing endless conflicts with changes coming in from
trunk.

C., keep two working copies, in case he want to work on something
else meanwhile, and want to avoid accidental commits

(D., use git-svn, and create a local only branch  - sic!)

Now, in Git, this idiot can do:

1., Have his own clone of the FPC repository. Create his local webassembly
branch, and keep happily working on his local copy, then leave it rot
when he loses motivation, doesn't distract anyone.

2., If he wants to involve others, he can publish his whole repository as
FPC-Webassembly project, independently from the main repository he forked,
and get others working on it. At this point his repository acts like an
independent fork of the compiler.

3., If his project succeeds (independent from the number of people worked
on his fork), then he can issue a pull request, while asking a review from
seniors on the FPC project. He can still do the changes requested from him
on his own repo, and commit them easily.

4., He can still sync his own repository with ease with the main FPC
project. So he can be sure when he sends his pull request, it will merge
seamlessly against the FPC master. (And this is in fact should be expected
from him.)

From the two above, I would go for the Git option. Because we're already
stuck with the first one in SVN, and it's not good. ;)

The bigger picture is, that I can do the SVN branch, because I had write
access to the SVN. But people without commit access, can't. So this also
makes difficult from people independent from the project work on larger
scale changes on their own... Or if they still do (hello NewPascal!),
because git-svn allows them, it's difficult for us to integrate their
changes back...

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

Re: [fpc-other] Git & SVN

Am 23.05.2017 um 21:56 schrieb Graeme Geldenhuys:
> On 2017-05-23 20:33, Karoly Balogh (Charlie/SGR) wrote:
>> Now, how the actual process would look with the FPC team, that's hard to
>> define at this point. But the tools are there for it.
> 
> Exactly what I was getting at.
> 
> 
>> Was this a proper answer, or I was beating around the bush in your views?
>> :)
> 
> Finally somebody that understands distributed version control, and how Git 
> could be used. You gave a
> very good answer indeed. Too many people (and companies) are so stead fast in 
> the ways of a
> client/server version control system - like SubVersion. They then wrongly (or 
> not ideal) force those
> ideas onto Git usage. Hence the reason I said it takes a bit or "rethinking 
> the problem", and in the
> end everything becomes quite clear.
> 
> For those interested, read the many blobs about how the Linux Kernel 
> development is managed. 

FPC is a compiler and not an OS kernel, so would like to see such blog posts 
from big compilers:
e.g. gcc, clang
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

Hi,

On Tue, 23 May 2017, Marco van de Voort wrote:

> The problem is that if problems get practical the advocatists suddenly step
> back and aren't really able to do more than regurgitate either the standard
> beginner "wisdoms" or "you shouldn't want this" or "this is the new improved
> ways" or similar platitudes.
>
> To get get back on track, I'll restate the question I posed in the last
> message unambigously:
>
> how to avoid that a push of member X doesn't leave a branch in an
> undesirable state that leaves member Y three choices:

How to avoid that member X with commit write access doesn't leave a branch
in SVN in an undesirable state? :) You have to trust people, and choose
who you give write access to a given branch/repository, really. This
didn't really change and not an argument against git.

And well, in Git you don't push, but people who want to contribute, have a
pull request. Then you can review that, and either apply to your tree or
reject it. It's important to understand that in git all repositories are
equal, and that I have a "make-amiga-great-again" branch, doesn't mean
that you should have it, I could still send a pull request against your
master branch, or whatever branch. All pull requests are just a set of
changes, really.

> 1. push anyway and make the mess worse
> 2. hold the commit/push
> 3. clean the mess himself.

Well, ideally in distributed teams, people don't push, but have a pull
request. Basically as crazy as it sounds, everyone forks the project all
the time, but then you have a set of tools to reintegrate all those forks
easily. It's the responsibility of the maintainer of a given branch to
accept that pull request or not, or request further changes before its
accepted.

> In your own repository that is no problem, and even in companies this only
> takes only a few LART/cluebat applications to fix. However in distributed
> teams this is a pain.

No, it isn't. This is the primary problem git solves, actually, by making
it possible for everyone having their own sandbox to play with, and you
have a review filter before accepting changes. You can even sign off
changes by a maintainer, who reviews the code. All those messy branches
remain local if they're not approved, on the person's computer who messed
it up, they don't have to go global/upstream...

And talking about myself - as much as I enjoy just committing my crap to
trunk, I sometimes would really prefer review. Not because I'm not a
senior engineer, but especially because of that... Now if I don't want to
do a branch in SVN which are huge and expensive (Git branches are cheap
and small), I either have to commit it first anyway to trunk, then ask for
a review, or send a patch for review first in e-mail, which is quite
cumbersome. Plus there's absolutely no warranty, that I later commit the
same patch which was reviewed.

At work, I don't even push against master, but I do a pull request against
my own repository, and ask one of my senior colleagues to review... I
don't know about you, but to me this sounds a lot more like teamwork, than
going around beating up people "for wrongdoing" with a cluestick.

Of course in the end it's just like crypto - you need to have a chain of
trust from the top, a group of trustees who will do the actual merging of
the pull requests, reviews and then push it upstream/mainline/trunk. If
one of these maintainers do a bad job, then you need to sort out that
problem, but that doesn't mean the whole system is broken. It's similar to
giving commit access to a developer who doesn't deserve it in SVN, really.

Now, how the actual process would look with the FPC team, that's hard to
define at this point. But the tools are there for it.

Was this a proper answer, or I was beating around the bush in your views?
:)

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

Re: [fpc-other] Git & SVN

In our previous episode, Karoly Balogh (Charlie/SGR) said:
> > Git just doesn't do KISS.
> 
> You need an SVN server to start working with SVN. With Git, you go to a
> directory, do "git init" and start committing. Everything is local. Not
> sure how that's not KISS. (You can add a remote later, and then push to
> it, with the full history intact. This remote can even be an SVN repo.)

The previous discussions were about team use of GIT, to be specific, FPC
core repo.

The problem is that if problems get practical the advocatists suddenly step
back and aren't really able to do more than regurgitate either the standard
beginner "wisdoms" or "you shouldn't want this" or "this is the new improved
ways" or similar platitudes.

To get get back on track, I'll restate the question I posed in the last
message unambigously:

how to avoid that a push of member X doesn't leave a branch in an
undesirable state that leaves member Y three choices:

1. push anyway and make the mess worse
2. hold the commit/push
3. clean the mess himself.

In your own repository that is no problem, and even in companies this only
takes only a few LART/cluebat applications to fix. However in distributed
teams this is a pain.



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

Re: [fpc-other] Git & SVN

Am 23.05.2017 um 12:42 schrieb Graeme Geldenhuys:
> On 2017-05-23 11:31, Tomas Hajny wrote:
>> the other, but let me remind you, that it isn't just about Florian. During
>> the previous discussions on this evergreen topic, Florian, Marco, Jonas
>> (if I remember correctly) and others raised quite a few specific questions
>> on how to accomplish particular tasks commonly used in the FPC project. I
>> may have missed something, but I haven't noticed a particular proposal
>> from you or anyone else describing in detail how to cover those needs
> 
> To be honest, I can't actually remember seeing any such proposal (asking for 
> advice or help) in the
> FPC-Users mailing list. Maybe it was in a list I'm not subscribed in? 
> Otherwise, I would have
> happily given my advice.

First problem: quote from core:

Am 05.03.2017 um 20:53 schrieb Jonas Maebe:
> On 05/03/17 14:33, Maciej Izak wrote:
>> Mhm. It hapens also for simplified github import for svn
>> (https://help.github.com/articles/about-github-importer/). My
>> proposition is :
>>
>> git svn init -s http://svn.freepascal.org/svn/fpc
>> :repeatloop
>> git svn fetch
>> If %ErrorLevel%==1 (
>> Goto :repeatloop
>> )
>>
>> (this command is for repo with all branches, instead of -s I have used
>> for NewPascal --trunk=trunklink but in theory -s should work...)
>
> It doesn't abort with errors (except at some point because we created a 
> branch called "avr", deleted
> it, then again created a branch with that name -- but that can be worked 
> around). It simply does not
> imports some revisions, or does not classify them under the right branches.


But actually, as long as llvm and gcc still use svn, svn should fulfill our 
needs as well :)
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

2017-05-23 Thread Sven Barth via fpc-other

On 23.05.2017 18:00, Karoly Balogh (Charlie/SGR) wrote:
> Also, ever tried to do partial commits in SVN? (Not committing all the
> changes in a single file.) (git add --patch)

To be fair: at least on Windows that is very easy with the help of
TortoiseSVN :)

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

Re: [fpc-other] Git & SVN

Am 23.05.2017 um 18:00 schrieb Karoly Balogh (Charlie/SGR):
> Hi,
> 
> On Tue, 23 May 2017, Martin Frb wrote:
> 
>> Or maybe they haven't forgotten how nice and simple svn is.
> 
> Erm, I really don't want to be involved in the usual religious war,
> personally I use exclusively Git these days (for personal stuff), but I
> don't mind SVN, CVS, or whatever a project uses I'm working on. But.
> 
>> Git just doesn't do KISS.
> 
> You need an SVN server to start working with SVN.

Every tried:

C:\temp>svnadmin create repos

C:\temp>svn checkout file:///c:/temp/repos wc
Checked out revision 0.

?

> 
> Also, ever tried to do partial commits in SVN? (Not committing all the
> changes in a single file.) (git add --patch)

I do it daily with FPC (using TortoiseSVN though).

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

Re: [fpc-other] Git & SVN

Hi,

On Tue, 23 May 2017, Martin Frb wrote:

> Or maybe they haven't forgotten how nice and simple svn is.

Erm, I really don't want to be involved in the usual religious war,
personally I use exclusively Git these days (for personal stuff), but I
don't mind SVN, CVS, or whatever a project uses I'm working on. But.

> Git just doesn't do KISS.

You need an SVN server to start working with SVN. With Git, you go to a
directory, do "git init" and start committing. Everything is local. Not
sure how that's not KISS. (You can add a remote later, and then push to
it, with the full history intact. This remote can even be an SVN repo.)

Also, you retain the full commit history locally, so you don't need access
to the server to get logs, get diffs, etc. Ever tried to work on a project
hosted in a centralized VCS, while on a 10 hour plane flight with no
internet? Or travelling in another country, where your roaming doesn't
work?

Also, ever tried to do partial commits in SVN? (Not committing all the
changes in a single file.) (git add --patch)

Also, ever tried to just make clean build of trunk quickly in SVN then
reapply your local, not committed changes? Or try your local changes
on another branch without committing them? (git stash)

Agreed, Git adds some complexity due to it's distributed nature, and
because you don't have nice monotonously increasing revision numbers. But
seriously, it makes a billion things much simpler and easier in exchange,
especially if one learns to exploit its features for the everyday
workflow. It's a tool to manage your source code, even *before* you commit
your changes. While SVN is still seen and used by many people as some kind
of "incremental source backup". And indeed, it's barely useable for
anything more, if we're honest.

But as I said, I'm fine with $whatever VCS, I'm not forcing anyone. Heck I
still see great software developed in CVS or even without any VCS (that's
quite extreme tho', admitted), because no tool can replace a great
developer. But great developers know how to make their own life easier. ;)

My 2 cents,
--
Charlie
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

2017-05-23 Thread Martin Frb


On 23/05/2017 16:04, Graeme Geldenhuys wrote:


WTF? Branching and Merging are two key feature of Git. So if the don't 
want merging (or only allow fast-forward merges), I guess they want to 
Rebase everything everybody contributes - yeah the lovely linear 
history of SubVersion because they don't know better.


Or maybe they haven't forgotten how nice and simple svn is.

Git just doesn't do KISS.

---
(I use both git and svn, and both have things that I personally miss on 
the other)


But at least this thread is highly amusing, so thanks for that ;)

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

Re: [fpc-other] Git & SVN


On 2017-05-23 15:23, Marco van de Voort wrote:

some info is at
http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git

merging, external repos were some of the other issues.


Good Lord, who wrote that, and when? Clearly someone with a serious lack 
of Git knowlegde - just the thing I described 2 replies ago.


"
However, we propose to mandate making merge commits illegal in our
canonical Git repository.
"

WTF? Branching and Merging are two key feature of Git. So if the don't 
want merging (or only allow fast-forward merges), I guess they want to 
Rebase everything everybody contributes - yeah the lovely linear history 
of SubVersion because they don't know better.



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 & SVN

On 2017-05-23 15:09, Mark Morgan Lloyd wrote:

One question if I may. Subversion has revision numbers like 12345, and
it's comparatively easy to query that and build it into a piece of
software's version information.

And the same is true for Git. By design, distributed version control 
systems (any of them, not just Git), can't rely on a sequential number. 
The word "distributed" should say it all. True parallel development; no 
single "server" instance etc.

Saying that, git includes a command 'git describe' which does what you 
need. I find its result also way more useful and informative that a 
single sequential revision number - which only has a mean to a 
developer. Lets use an example:

  [reportdesigner (reportdesigner)]$ git describe
  v1.4.1-787-g45f932c1

What does that output tell me:
  * Whatever code I'm working on is follow on from the "v1.4.1"
release.
  * This line of [development] history has seen "787" commits
since the v1.4.1 release.
  * The "g" prefix indications that the Git revision control
system was used.
  * The "45f932c1" is the SHA1 value of the last commit, that
uniquely identifies where we are in the whole history of
the project. Irrespective of having 1 or a 1000 branches.

Now as with anything Git, everything is configurable. So the 
git-describe commands has many optional parameters too. So you can 
change the output to suite your project's needs. Things like should Tag 
names be used in the git-describe output, or only Annotated Tags, or 
only Branch names. Do we want the commit count, do we want the "g" 
prefix, how long SHA1 value do we want etc etc.

Many applications incorporate such output in there version information. 
See attached screenshot of one such example. I've seen plenty of others too.

What does a SubVersion revision r20453 tell you?

  * Which branch are you on?
  * Which release is this work based on?
  * Is it a "hotfix" or new feature.
  * Is it maybe a tag? Though Subversion doesn't really have a
concept of tags, as they are just branches in a bad disguise.

No, it only tells you that you are using commit number 20453.

So now the next thing you are probably going to tell me is that yeah but 
I can use the revision number in Windows's version numbering as a 
Revision or Build value. Yes and No. Only if your repository has less 
than 65535 commits - the maximum a WORD type supports. So what happens 
if you have more commits that that? Many large projects do.

> It's also trivial for a developer to
> look at the revision that he's currently working with, to say whether
> it's older or newer than revision 12345,

As I just explained. The git-describe output tells you that and more.

> and to get a log of what the
> relative changes were by /only/ knowing the revision number.

Nothing new, Git does that too. Git (no surprise) even goes further and 
also tells you the Parent(s) commit that got you there, the 
Child/Children commits following on, what branch it is on and what Tags 
this commit follows.

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 & SVN

In our previous episode, Mark Morgan Lloyd said:
> Now I don't deny for a moment that Git has its advantages for 
> distributed working. But am I correct in my understanding that it has 
> nothing that maps directly onto the monotonic revision list of 
> traditional VCSs including Subversion?

Nope. There is only some hash, and various hacks to emulate with post commit
hooks, which is not at all the same in behaviour.

some info is at
http://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git

merging, external repos were some of the other issues. (Potentially) solved 
issues since
the previous discussion were repo dictated configuration (for linefeeds),
and the ability to avoid certain branches to have multiple ends (thus
leaving the next committer with the unenviable choice to wait or potentially
make the situation even more complex).

All from memory of ourse.
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN

2017-05-23 Thread Mark Morgan Lloyd

On 23/05/17 14:00, Marco van de Voort wrote:

In our previous episode, Graeme Geldenhuys said:> As with any new applications or technologies,
there is always some > learning curve (big or small). There are tons of bad habits ingrained in
> SVN users. Those do not translate well to Git (thank goodness). Git > works fundamentally
different to SVN (for the better). So you need a > change in mindset - some refuse, hence they
struggle with Git. And then > wrongly blame Git for it. I fear this is most likely what happened
with > Florian.
That is your very colored view about it, that automatically declaresnon-gits
stupid.
However in the last discussion we showed you various faqs (like from LLVMand
FreeBSD) that mirrored the FPC core teams.

One question if I may. Subversion has revision numbers like 12345, and
it's comparatively easy to query that and build it into a piece of
software's version information. It's also trivial for a developer to
look at the revision that he's currently working with, to say whether
it's older or newer than revision 12345, and to get a log of what the
relative changes were by /only/ knowing the revision number.

Now I don't deny for a moment that Git has its advantages for
distributed working. But am I correct in my understanding that it has
nothing that maps directly onto the monotonic revision list of
traditional VCSs including Subversion?

--
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 & SVN

2017-05-23 Thread DaWorm

emacs!  vi!

Let's call the whole thing off and use EDLIN.
___
fpc-other maillist  -  fpc-other@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-other

Re: [fpc-other] Git & SVN