Hi,
Στις 2017-05-26 13:55, Sven Barth via fpc-other έγραψε:
2017-05-25 17:24 GMT+02:00 Dimitrios Chr. Ioannidis via fpc-other
:
< snip >
Ok just setup gogs for testbed / evaluation at
https://fpc-scm.nephelae.eu/
.
Anyone interested for admin credentials for evaluation just email me
privat
2017-05-25 17:24 GMT+02:00 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 jus
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
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 in
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 branche
2017-05-25 16:13 GMT+02:00 Karoly Balogh (Charlie/SGR)
:
> Hi,
>
> On Thu, 25 May 2017, Dimitrios Chr. Ioannidis via fpc-other wrote:
>
>> > 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
Hi,
Στις 2017-05-25 17:13, Karoly Balogh (Charlie/SGR) έγραψε:
Hi,
On Thu, 25 May 2017, Dimitrios Chr. Ioannidis via fpc-other wrote:
< snip >
who needs github when you have gogs ( https://gogs.io/ ) ?
It's a 5 minute setup and is very solid .
Actually, the irony is strong with this one,
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 a
Hi,
On Thu, 25 May 2017, Dimitrios Chr. Ioannidis via fpc-other wrote:
> > 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
> > Req
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 Gi
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 compiler/ and rtl/. An
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 which don't build for
> any
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 compiler/ and rtl/. And even for half of the RTL.
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 llvm
Hi,
On Thu, 25 May 2017, Sven Barth via fpc-other wrote:
> nevertheless Charlie's mail was too interesting and constructive not
> to respond to it :)
Awww, you, stop it... *blushes* :D
> Of course the biggest obstacle is the building and running of the
> testsuite.
Well. Build breakages are da
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 is too big for the migratio
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
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 c
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 outwe
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
designe
Am 25.05.2017 um 00:18 schrieb 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.
To avoid that people get the impression we do not
On 24/05/17 02:46, nore...@z505.com wrote:
> 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,
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 :)
___
fpc
Am 25.05.2017 um 02:13 schrieb Nikolay Nikolov:
> Here's an analogy of how the git bible-thumping looks to a subversion user:
[...]
> In fact, you can easily fit a lot
> more people in the truck. You just put benches in the cargo area.
Great comparison :)
>
> I hope you get the idea ;-)
I fea
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 acces
In our previous episode, Graeme Geldenhuys said:
> 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 co
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 access to Trunk.
Oh wait, I can answer that very accura
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".
T
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 build
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
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
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 et
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, feat
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'
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 int
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
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
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 paramete
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 l
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
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/Gi
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
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 k
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 "
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
pre
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,
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 work
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
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 a
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
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 comm
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
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 everythi
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
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 too
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 Bu
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
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
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 pr
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 lik
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 (
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
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.)
I'
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 l
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..
___
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 no
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,
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
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
pe
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 multip
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 practic
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-
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
Am 23.05.2017 um 22:24 schrieb 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
>>
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, bu
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
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 :)
__
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:
>
>
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 pr
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?
:)
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
Hi,
On Tue, 23 May 2017, Florian Kl?mpfl wrote:
> Every tried:
>
> C:\temp>svnadmin create repos
>
> C:\temp>svn checkout file:///c:/temp/repos wc
> Checked out revision 0.
>
> ?
No, nice to know this works, thanks. However, then if you try to publish
this repo outside of your computer, it gets
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, an
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
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
_
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
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
On 2017-05-23 16:17, Martin Frb wrote:
Git just doesn't do KISS.
Git is as complicated as you want it to be.
If you want to use it like SVN, then go right ahead. You will miss out a
lot though. I always recommend newcomers to start out with the basic 4-5
commands (same as SVN). Then as you
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 d
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
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 (
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
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 goo
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
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 t
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 tas
On Tue, May 23, 2017 11:23, Graeme Geldenhuys wrote:
> On 2017-05-22 23:11, nore...@z505.com wrote:
Hi Graeme,
.
.
> 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
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
98 matches
Mail list logo
