Re: [fpc-other] Git & SVN

2017-05-25 Thread Dimitrios Chr. Ioannidis via fpc-other
Hi, Στις 2017-05-25 18:24, Dimitrios Chr. Ioannidis via fpc-other έγραψε: Hi, Στις 2017-05-25 17:34, Sven Barth via fpc-other έγραψε: < snip > a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server... Ok just setup

Re: [fpc-other] Git & SVN

2017-05-25 Thread Dimitrios Chr. Ioannidis via fpc-other
Hi, Στις 2017-05-25 17:34, Sven Barth via fpc-other έγραψε: < snip > a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server... Ok just setup gogs for testbed / evaluation at https://fpc-scm.nephelae.eu/ . Anyone

Re: [fpc-other] Git & SVN

2017-05-25 Thread Graeme Geldenhuys
On 2017-05-25 15:34, Sven Barth via fpc-other wrote: a core dev). Though we'd need to implement such restrictions anyway no matter what we choose for the repo hosted on our own server... Gitolite is brilliant at directory level, file level, branch level, site level permissions, private

Re: [fpc-other] Git & SVN

2017-05-25 Thread Dimitrios Chr. Ioannidis via fpc-other
Hi, Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε: < snip > Maybe such a hypothesized integration system would be a bit more rigorous depending on what files were changed? E.g. full build with fullcycle plus testsuite run on Tier 1 targets if anything in compiler and rtl was changed

Re: [fpc-other] Git & SVN

2017-05-25 Thread Dimitrios Chr. Ioannidis via fpc-other
Hi, Στις 2017-05-25 16:53, Sven Barth via fpc-other έγραψε: < snip > Step 1: have an official FPC trunk Git mirror on our own server with a mirror/fork of it on GitHub (were those license troubles regarding GPL and Co I mentioned some months ago solved, btw?) and accept Pull Requests on the

Re: [fpc-other] Git & SVN

2017-05-25 Thread Sven Barth via fpc-other
2017-05-25 15:34 GMT+02:00 Marco van de Voort : > In our previous episode, Sven Barth via fpc-other said: >> Of course the biggest obstacle is the building and running of the >> testsuite. > > I think running the testsuite is a waste of time and cycles for anything > outside

Re: [fpc-other] Git & SVN

2017-05-25 Thread Sven Barth via fpc-other
2017-05-25 15:20 GMT+02:00 Karoly Balogh (Charlie/SGR) : >> Of course the biggest obstacle is the building and running of the >> testsuite. > > Well. Build breakages are daily occurence with obvious "this could have > never built" mistakes, or new packages get committed

Re: [fpc-other] Git & SVN

2017-05-25 Thread Marco van de Voort
In our previous episode, Florian Kl?mpfl said: > > donate a month of our time. > > Indeed, it depends on the person who does it. It requires knowledge about the > specific workflow > requirements of a compiler project. And that this is not easy is proven by > the fact that gcc as well > as

Re: [fpc-other] Git & SVN

2017-05-25 Thread Sven Barth via fpc-other
2017-05-24 14:12 GMT+02:00 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

Re: [fpc-other] Git & SVN

2017-05-25 Thread Florian Klämpfl
Am 25.05.2017 um 12:02 schrieb Graeme Geldenhuys: > On 2017-05-25 09:26, Florian Klämpfl wrote: >> This is at least one month of work I (and >> probably nobody else) can and want to spent. > > And some how I believe that will never happen (or be allowed) even if I (or > somebody else) decide to

Re: [fpc-other] Git & SVN

2017-05-25 Thread Marco van de Voort
In our previous episode, Santiago A. said: > Workflows are designed according with the tools you had when you > designed it. Sometimes you improve your workflow as you improve your > knowledge of tools. And sometimes you create new tools to improve your > workflow. > > But sometimes other people

Re: [fpc-other] Git & SVN

2017-05-25 Thread Graeme Geldenhuys
On 2017-05-25 09:26, Florian Klämpfl wrote: This is at least one month of work I (and probably nobody else) can and want to spent. And some how I believe that will never happen (or be allowed) even if I (or somebody else) decide to donate a month of our time. I fear the resistance will

Re: [fpc-other] Git & SVN

2017-05-25 Thread Santiago A.
El 24/05/2017 a las 22:07, Florian Klämpfl escribió: > > The workflow will not change. If the tool does not fit the workflow, it is > the wrong tool. Period. I'm not an apostle of Git, nevertheless, your statement is wrong. Workflows are designed according with the tools you had when you

Re: [fpc-other] Git & SVN

2017-05-25 Thread Florian Klämpfl
Am 25.05.2017 um 00:44 schrieb Graeme Geldenhuys: > But I get in now. You guys are set in your ways - good or bad, and currently > not willing to change. > So I'll leave it at that. Thanks. I hope I might quote you in a few weeks/months/years :) ___

Re: [fpc-other] Git & SVN

2017-05-24 Thread Nikolay Nikolov
On 05/25/2017 01:44 AM, Graeme Geldenhuys wrote: On 2017-05-24 21:21, Marco van de Voort wrote: Even a limited change is already a massive operation, let's keep it managable. So how large is the FPC team really? I'm talking about active developers on a day-to-day basis who have commit

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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".

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

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

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread 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

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,

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

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

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,

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

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

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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.

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

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,

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

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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.

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-24 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread noreply
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread noreply
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread noreply
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread noreply
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..

Re: [fpc-other] Git & SVN

2017-05-23 Thread noreply
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread noreply
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Karoly Balogh (Charlie/SGR)
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Florian Klämpfl
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 -

Re: [fpc-other] Git & SVN

2017-05-23 Thread Karoly Balogh (Charlie/SGR)
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Karoly Balogh (Charlie/SGR)
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,

Re: [fpc-other] Git & SVN

2017-05-23 Thread Marco van de Voort
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Florian Klämpfl
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 :)

Re: [fpc-other] Git & SVN

2017-05-23 Thread Karoly Balogh (Charlie/SGR)
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: >

Re: [fpc-other] Git & SVN

2017-05-23 Thread Florian Klämpfl
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Karoly Balogh (Charlie/SGR)
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Marco van de Voort
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,

Re: [fpc-other] Git & SVN

2017-05-23 Thread Florian Klämpfl
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

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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Florian Klämpfl
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread 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

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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Graeme Geldenhuys
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

Re: [fpc-other] Git & SVN

2017-05-23 Thread Marco van de Voort
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?

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

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

2017-05-23 Thread Marco van de Voort
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