Jump to content
RadStudio 10.3.1 was released today Read more... ×

Recommended Posts

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 by dummzeuch
  • Thanks 1

Share this post


Link to post
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!

1912315494_Screenshot2019-02-01um13_55_45.png.b2f469d36bf60fe4e5ebc68fe0bdc511.png

 

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 by Ondrej Kelle
  • Like 1
  • Thanks 2

Share this post


Link to post

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.

  • Thanks 1

Share this post


Link to post

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

  • Like 1
  • Thanks 1

Share this post


Link to post
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!

1912315494_Screenshot2019-02-01um13_55_45.png.b2f469d36bf60fe4e5ebc68fe0bdc511.png

 

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. 

  • Thanks 1

Share this post


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

I would suggest Git or Mercurial.

Thanks Dalija Prasnikar.

Share this post


Link to post
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.

Share this post


Link to post
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. 

Share this post


Link to post
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 !OI.png.89b15df2b358bef55791ff2f91322889.png

Share this post


Link to post

Hi all...:classic_cool:

Quote

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

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

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

Edited by haentschman

Share this post


Link to post

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

Share this post


Link to post
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

Share this post


Link to post

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.

  • Like 2
  • Thanks 2

Share this post


Link to post
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...

Share this post


Link to post

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

Share this post


Link to post

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 by ByteJuggler
  • Thanks 2

Share this post


Link to post

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 by stijnsanders
  • Like 2

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×