version control system Version Control System

[dummzeuch 1505]

On 2/1/2019 at 4:49 PM, Anders Melander said:

If you need your source hosted in the cloud I think GIT is the best solution. There are SVN hosting solutions but in my experience they aren't very good.

SourceForge had a time with technical problems (not only with svn), and it took them quite a while to sort them, but they are now back to being reliable and fast.

 

During that time I moved many of my open source projects to OSDN (which started off as a SourceForge clone). They are also quite good.

 

Also, github offers svn access to git repositories. It works for simple cases. My most treasured feature of svn - externals - is not supported though.

 

But of course these are mostly for open source projects. I would not use a cloud service for proprietary sources at all.

Edited February 3, 2019 by dummzeuch

[Guest]

21 hours ago, Sherlock said:

On a totally unrelated matter I would like to direct your attention to a completely underrated feature of Delphi: LiveBlame - in the IDE!

 

This however works with hg,git and Subversion. But I just love this! I love to put blame on others, and then find out it was my fault after all! 😄

 

 

People have actually asked for blame as a feature, that's why I included it back then in delphisvn (before it became Version Insight).

I find it useful myself to see who committed which lines and also when. This piece of metadata can be useful when trying to understand a code base and its evolution.

 

Edited February 2, 2019 by Guest

[Hans J. Ellingsgaard 21]

Bitbucket is a great  versioning system based on git. You can have 5 users for free, so you can always give it a try. It works well with Sourcetree as a client. It,s also easy to integrate with Jira.

[Allen@Grijjy 44]

GiT - don't waste your time on anything else.  Lots of client choices, but most all it has such broad community support.

[M.Joos 30]

On 2/1/2019 at 2:14 PM, Sherlock said:

On a totally unrelated matter I would like to direct your attention to a completely underrated feature of Delphi: LiveBlame - in the IDE!

 

This however works with hg,git and Subversion. But I just love this! I love to put blame on others, and then find out it was my fault after all! 😄

 

AFAIK this is not a feature of the official Delphi IDE, but rather a plugin from Uwe Schuster that is no longer supported for recent Delphi version. Correct me if I am wrong as I love live blame very much, but can't use it except for Delphi XE. 

[Darian Miller 361]

I suggest SVN hosted by Assembla

https://www.assembla.com/subversion

 

Or CloudForge

http://www.cloudforge.com/features/

 

[Soji 1]

On 2/1/2019 at 4:20 PM, Dalija Prasnikar said:

I would suggest Git or Mercurial.

Thanks Dalija Prasnikar.

[Soji 1]

On 2/1/2019 at 4:49 PM, Anders Melander said:

I'd recommend SVN or GIT - and since someone dared to mention it, I'd also like to warn against TFS. It's an abomination and just a tiny improvement over VSS.

Thanks Anders Melander.

[Sherlock 663]

14 hours ago, M.Joos said:

AFAIK this is not a feature of the official Delphi IDE, but rather a plugin from Uwe Schuster that is no longer supported for recent Delphi version. Correct me if I am wrong as I love live blame very much, but can't use it except for Delphi XE.  

Oh, yes you are right. It is not built in. But it works with Rio! What I posted however is a screenshot with Tokyo.

You can get the plugin here: https://github.com/MJSt/DelphiVersionInsight

Compile it and activate the add-in DLL via a tool like GExperts Expert Manager. 

[M.Joos 30]

6 hours ago, Sherlock said:

Oh, yes you are right. It is not built in. But it works with Rio! What I posted however is a screenshot with Tokyo.

You can get the plugin here: https://github.com/MJSt/DelphiVersionInsight

Compile it and activate the add-in DLL via a tool like GExperts Expert Manager. 

Thanks a lot, works like a charm, also in RIO. Now if you would also have the "old" Object Inspector Expert from Uwe ..... that would be a dream !

[haentschman 92]

Hi all...

Quote

Now if you would also have the "old" Object Inspector Expert from Uwe ..... that would be a dream !

The last version was imho XE. I've written to Uwe before... without an answer. Everyone who knows Uwe has no contact more...

@Uwe Schuster: We need only the SourceCode...please.

Edited February 5, 2019 by haentschman

[Sherlock 663]

Just to be clear, Uwe Schuster is the one who wrote that expert. Not Uwe Raabe.

[haentschman 92]

Quote

Uwe Schuster

...everybody knows it...i think

[John Kouraklis 94]

I use SourceTree as well. It has some glitches but in general saves lots of command-line work

[Dave Nottage 557]

3 hours ago, John Kouraklis said:

I use SourceTree as well. It has some glitches but in general saves lots of command-line work

+1000 for SourceTree on macOS. Not as enthused about the Windows version

[David Hoyle 68]

I moved from JEDI VCS (don't laugh) to Git about a year ago and I don't regret it one bit. Git provides me with functionality that's invaluable especially if used with Git Flow. I use SourceTree as recommended above for most of the work (dark theming coming soon to Windows) but it cannot do all the full Git Flow so I've created some Custom Actions for the missing bits or just drop to the command line. If you want to learn more there is a PDF called Git Pro (https://git-scm.com/book/en/v2) which is definitely worth a read.

[Sherlock 663]

10 hours ago, David Hoyle said:

moved from JEDI VCS

That still has users? I loved it back in the day (around, oh...8 years ago), and actually miss it some times. I have the occasional merge conflict, that a pascal enabled merge tool wouldn't even think about, but have to keep dreaming of a language aware merge...

[David Hoyle 68]

I find winmerge works fine for both diff and merge but since I’m the only developer of my software it’s rare that I’ll do any parallel flows of work

[ByteJuggler 45]

We've been using SVN for many years now, no complaints.  We're however planning to migrate to Git at some point, and are already using it in parallel with SVN in several ways.  It is perhaps worth it to note that from a size efficiency perspective Git is much more efficient than SVN.  The total size of a git repo + working copy files (which remember, includes all the branches and the entire history of the project locally) is typically quite a bit smaller than an SVN checkout (which only contains the working copy and a copy of the pristine files of a single branch with no history.) So any history investigation or switching between branches requires a connection to the remote SVN server, whereas Git does not require this and allows complete freedom to switch branches, create new ones and interrogate the histories offline.  This is extremely useful when you want to do some types of work where a connection to your central version control system is not available.

 

To also note: It is entirely possible to use both version control systems sort of independently at the same time, by making each ignore the other's folders.  This has benefits as it starts making the notion of "I have a local repository that I can work against" apart from "the remote" clearer.  E.g. commit whatever you like, in as small baby steps as you like against your own development git repo, and once ready commit to your "mainline" SVN repo.  Meanwhile when upstream updates happen you get practice in merging and learning how to do this properly using git.  Eventually this sets you up to simply swap the step that commits to SVN to pushing to a remote Git repo instead.  

 

It is also possible to keep a git repo as part of your SVN repo, if needed/wanted/useful.  For example, we use and keep third party sources in a dedicated third party SVN repository, and in several cases for ease of updating to ("pulling in") the latest version of the open source project and to have access to the history of these projects, the path of least resistance was to actually commit the git repo into our Subversion repo.  To update then is simply a case of pulling from the repo on github, checking if the update breaks anything and then commiting both the source changes and the changes to the git repo to subversion.  

 

(One more addition: Another department actually also use Bazaar, it works well but I'd not recommend it as it's essentially dead in terms of development, and the plan is to eventually migrate that to git too.  For clients we use the Tortoise* tools.)

Edited February 7, 2019 by ByteJuggler

[stijnsanders 35]

I made my own diff just to get it the way I want it: DirDiff

What I didn't want is the stuff that's the same for both twice on screen. The last re-work I did on it enabled diffs between 3 or more files, but that's still not exactly what's needed for conflict resolution.

I've open-sourced it here: Github...

Edited February 8, 2019 by stijnsanders

[Davide Visconti 5]

We use Mercurial and TortoiseHg.

It'sworks very well in Windows environment.

[Lars Fosdal 1792]

How does SourceTree and Github Desktop compare?

[Lars Fosdal 1792]

On 2/5/2019 at 7:01 AM, haentschman said:

Hi all...

The last version was imho XE. I've written to Uwe before... without an answer. Everyone who knows Uwe has no contact more...

@Uwe Schuster: We need only the SourceCode...please.

He lives at https://twitter.com/uscle?lang=en

[haentschman 92]

Now all we need is a Twitter account... I don't have one.

 

[haentschman 92]

Hi...

 

News from Uwe? Did someone contact him via Twitter?

PS: I have found the "Favorites" (Berlin) in a picture from his Twitter account. The project is alive...i hope.

 

 

Edited May 13, 2019 by haentschman