Alternative to using Xcode with Subversion - xcode

Seemed great to have subversion integrated in Xcode. However it is very primative compared to other IDEs. Are there another programs out there that I can use to manage Subversion for my iPhone project?

Versions can do a lot of the things that go beyond what the SVN integration in Xcode can do.

I use SmartSVN and like it a lot. Even the free-of-charge Foundation version is decent IMO. You may also try Professional version for a month to decide whether you need it. Features I like most: change sets (Pro only), applying patches (Pro only), their built-in change viewer + editor. The built-in conflict solver could be better, but an external tool can be used instead.

Related

Need some pointers/hints in writing a Windows Application

I want to create applications in windows that has complete portability (within windows OSes of course). I have tried using one application written in Visual C++ but I had a real tough time in making it run in other windows OS (like it required .net framework libraries to be installed). This put me on the back foot because I had to copy a set of DLLs from one machine to another and most of the time something works some does not.
And I am TOTAL amateur in writing windows based applications since my technological forte is mostly Java. Where to kick off? (like which tools/IDEs to begin with since I am seriously into writing my own utilities/tools).
I am open to clarification should you guys feel my question is vague/blunt.
Thanks.
Visual C++ should be easily able to do what you want. It sounds like you created a C++/.NET project, which will generate a dependency on the .net libraries. You need to choose a different project type when the wizard starts up.
If you have a paid version of Visual C++, you might try clicking on "MFC Application". A lot of people are down on MFC these days, but it's still a quick way to get a C++ Windows app off the ground. Make sure you choose the option to statically link the MFC libraries, or you'll have another dependency.
MFC isn't included in the free version of Visual C++, so you'll need to go old-school and work directly with the Windows API or find another package such as QT or Wx to link with.
You can use .NET, and if you stay in 2.0, use standard components, it should work fine. You may need to make a few changes to work anywhere, buy very possible.
http://www.mono-project.com/Main_Page
You could either use Visual Studio or the free IDE. Sharp develope or Mono Develope.
If you really want it to work on every version of windows your best bet may be to go the route of full cross-compatibility. Grab the Boost, QT, and possibly ACE libraries and stay away from making OS calls directly. There's a free version of Visual Studio which is probably what you want for an IDE for personal development, if you're doing commercial stuff then get the full version.
Why not use Java. The JVM is on more systems then .NET and now your app will work on any OS not just windows. Plus java is easier for a beginner then C/C++ and less chance that your program will cause BSODs.

Adding support of Windows to POSIX project... How painful? Is it worth the effort?

I'm trying/thinking of making CppCMS - C++ Web Framework project little bit more cross platform.
Today I can easily support Linux, OpenSolaris, FreeBSD and even Cygwin. But when it comes to Native Windows it becomes really painful:
The overview of the situation:
I'm POSIX/Linux developer and I'm barely familiar with Native Windows development tools like Visual Studio and Win32 API. However I do some work for this platform so I understand the limitations and the fact that Windows is totally different world.
This is web project that uses APIs that popular in Unix world, like: CGI, FastCGI and SCGI that implemented in most UNIX web servers; but I understand that I would not be able to use it with IIS because it does not support FastCGI over TCP/IP (only Windows pipes).
So even when it would work it would probably run only with Windows port of Apache.
I relay heavily on POSIX API:
Pref-forking allows be keep high survivability in case of crashing (not supported under windows) so this feature would be missing.
I use some file-locking facilities (but I can probably give them up without forking)
I have intensive use of native pthreads, even I can replace them with Boost.Thread
I probably would never be able to support Visual Studio (maybe 2010 with C++0x support), because I relay on C++0x decltype/auto feature or typeof/__typeof__ extension that is supported by most compilers I worked with: gcc, intel, sun studio. (To be honest: I can work without them but it makes the life much easier to framework user.
I relay heavily on autotools and I can't replace them with CMake, bjam or friends, because when it comes to support of internationalization, cross copiling, package management, they just does not give me a solution.
There are many annoying points like missing gmtime_r, or localtime_r under windows and many others that just require from me to rewrite them or replace them with 3rd part libraries.
There are still many "UNIX like" libraries that ported to Win32 like: iconv, gcrypt and some others that are barely ported like libdbi that have many limitations on windows.
Bottom line:
There is lots of non-trivial work to do, and even when it would be complete, it would probably work only with MingW tools and not "native" tools that Windows programmers are
familiar with.
So, my questions are:
Does such MingW port worth an effort? Would this help to build bigger community?
Does anybody have experience on how painful porting big projects from POSIX environment to
Win32 API is?
Would it be useful for Windows developers at all?
Edit:
It is also important for me to understand, how many of windows developers prefer to use
Open source development tools, MingW over Microsoft development solutions like VS.
Edit #2: Clearification about "native" windows solusions and IIS.
In fact, running framework with IIS is really hard problem. I explain:
The project relates to standard web server API as FastCGI or SCGI that allows to accept many requests over sinlge socket. Thus, on application side, I accept new request proceed it and returns the answer. Sometimes several threads process several requests.
Thus, implementing one or two standard protocols I open communication with any existing server: Apache, lighttpd, nginx, cherokee... or any other servers; with small exception of IIS
IIS has implementation of FastCGI, but... It supports only 1 connection per local process only that controlled by web server...
So... there is absolutely no standard way to connect my application to IIS.
Please note, I implement standard Web server API, I do not implement Neither IIS proprietary ISAPI nor Apache proprietary API, even the second is more important as for targeting UNIX world.
So, just Windows IIS Web world is just not really ready for cooperation for such project, so if anybody would use it under Windows it would use it with more open web servers.
You should base your decision on user demand. Have users ever requested using the framework on Windows? If so, did they explain why they wanted to use Windows (e.g. what additional constraints they had, what webserver they wanted to use, etc.)?
Typically, Windows users do expect that things work the Windows way. That means Visual Studio support, IIS support, MSI installer, and so on. If something still feels like being Unix, I would rather use Unix proper, instead of fighting with a half-working port.
As a windows client app developer it sort of hurts me that the development environment division currently is essentially Win32 and everything else and that they are mostly incompatible. That's why I'm preparing to move to MinGW for my personal windows app projects and to try to make them cross-platform.
I would suggest gradually moving to more cross-platform libraries like, as you suggested, refactoring pthreads to boost::thread, or going from fork() to multi-process with IPC, probably also using boost's facilities. Date/time stuff can be dealt with Boost libs as well. As for database support, there are
Microsoft compiler support is not that important I think, as MinGW provides a decent build environment with all the IDEs that support it, Eclipse CDT and Dev-C++ being among the most popular. But if you are going to make your project msvc-compatible, make sure users will be able to use Express editions of Visual Studio 2010 (as soon as thay come out) - that way no one will have to fork out for a Visual Studio 2010 (upgrade) just to use your project and there will be no problem for you to require the latest in Microsoft technology.
Most likely you won't avoid some amount of ifdefs for a code base of your project's size, but surely the effort might be worth it, if not only for gaining valuable experience and expanding the community with a few new happy and grateful members.
Your saying that you can support Cygwin quite easily reminds me that I've seen commercial Windows software that simply bundled in cygwin1.dll to support some originally-Unix code. If adding cygwin1.dll to your installer is all it takes, try it out.
I think you only have to look at the questions asked on SO to work out that MinGW users on Windows (of which I am one) are in a minority in the development community - the vast majority of Windows developers are using MS tools. Anyway, the compiler is only half (or less) of the issue - if your architecture depends on forking lots of processes, using MinGW is not going to help you. My advice is, if you really want to do cross platform development:
look at how Apache do it
consider using the Apache libraries as your base
don't use very new or compiler-specific language features
use multi-threading rather than multi-process
Does such MingW port worth an effort? Would this help to build bigger community?
I am still working myself on this issue with my own large POSIX project and my conclusion is that if you need to later interface with Microsoft products, then its worth while, however then I would only use MingW if project is medium small, if it is very large, then I would go all the way with MSDN Microsoft development tools - Huge amount of help will be available there - however it will cost
Does anybody have experience on how painful porting big projects from POSIX environment to Win32 API is?
sofar my own conversion of my POSIX project have been constantly put on hold, because of the amount of time each issue takes to handle is enormous - not finished converting yet - If I ever will be
Would it be useful for Windows developers at all?
Sure working inside the Microsoft IDE using tools from MSDN will definately decrease development time, however it will increase your dependence on Microsoft libraries - something you need to decide from beginning if that is an issue
**
Actually you could just add the necessary cygwin dlls to your projects make and then you would beable to run it in windows
I managed to make my POSIX project run when I added following dlls
cygboost_filesystem.dll
cygboost_system-mt-1_53.dll
cygboost_thread.dll
cyggcc_s-1.dll
cygstdc++-6.dll
cygwin1.dll
Probably your project will have different dependencies, however if you think conversion is not worth it, then perhaps this is a solution for you
You could also add your libs as static, then you would end up with only having to provide the last cygwin1.dll

Setting up an emacs environment in windows?

I am currently constrained to a windows dev box and I want to migrate my projects from eclipse to emacs.
What are some good references on setting up an emacs dev environment for windows? Anything that could assist in migrating from eclipse as well would be appreciated.
If you're used to windows behaviors (e.g. ctrl-c is copy, etc.), a good (customized) version of emacs for windows is the 'EmacsW32' package.
If you're looking at migrating away from eclipse, I assume that you probably want java support. For this you will want to get the JDEE package, also. Unfortunately, it's non-trivial to deploy on windows, as it depends on other packages (and requires cygwin or msys (pseudo-unix environments for windows) in order to install).
You may also want to install additional modes to support e.g. SCM systems, etc. A good source of information for this is the EmacsWiki. There's a significant amount of material there about emacs on windows, although some of it is out of date....
Sure, just download a prebuilt version and use it.
For example, as I use R a lot with the wonderful Emacs ESS mode, the prebuilt version by Vincent Goulet is really useful as it contains Emacs, ESS, Auctex (for LaTeX) and more.
Other prebuilds exist for Cygwin, MinGW, or plain old Windows.
Eclipse is pretty good on Windows; I'm a big user of emacs but for Java development I spend most of my time in Eclipse.
Regarding general use of emacs on windows I highly recommend you install GnuWin32, as it is much faster than Cygwin and integrates very well. Also see my blog post on Visual Studio tricks in emacs and this one on tags.
I'll assume you are doing Java development for the most part and that you would prefer not to be using Windows. This is a situation I find myself in from time to time. My preferences are to use a Linux machine (virutal or real) in addition to the Windows machine. Emacs just works better in a real Unix environment. And then use both Emacs and Eclipse where each is stronger. Emacs for editing, mail, planning, "thinking" type stuff and Eclipse for debugging, refactoring, some error fixing. Fortunately both Emacs and Eclipse make it easy to use both simultaneously.
I generally use EmacsW32 on a new box - it's a good option at least initially. I'd also recommend checking out the emacs starter kits which hook up to ELPA (http://tromey.com/elpa/), which allows you to get a usable setup pretty quickly.
Install Cygwin.
In your .emacs, load these two files, in this order:
http://www.emacswiki.org/emacs/download/cygwin-mount.el
http://www.emacswiki.org/emacs/download/setup-cygwin.el

C# mono from windows to mac

I wanted to know what i shouldn't do in code that will prevent my C# app from running on mac.
In general you shouldn't use anything from the Microsoft.* namespaces, no PInvoke (DllImport in C#) and UI might be problematic as well.
Further information on Mono compatibility is contained in the Mono Guide Porting Winforms Applications. Existing applications can be checked for compatibility using the Migration Analyzer tool.
UPDATE: PInvoke actually works in Mono, but if you want to have it working cross-platform you must provide a native shared library with the same interface for each platform (i.e. Win API most likely will not work).
Mono's Application Portability guide is a good reference.
In addition to divo's recommendations, I would recommend the Mono Migration Analyzer (MoMA) tool: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono"
Also, I would keep an eye on Miguel de Icaza's blog, and the Mono Project website.
In his presentation for the Boston.NET Users Group this month, he showed a preview of a Visual Studio plugin that launches your app on Mono using a VM! This lets you test compatibility during the development process.
I believe their goal was to release it at TechEd 2009, so look for an update over the next month or so.
You will, at the very least, want to try and avoid using Windows Forms, since that is just a paper-thin layer on top of the Windows native UI.
Mono emulates it somewhat with help from WINE, but I wouldn't trust that.
Mono did this a while ago but the effort was abandoned. See WinForms on Mono for more information. Thanks jpobst.
Try using GTK# or Qt# (although I'm not too sure the latter one actually exists) for cross platform support. You might also consider using Java with SWT or even Swing instead of C#, but that will probably not be an option you're willing to consider.
Using anything related to P/Invoke is probably also a bad idea, since that invokes native code which will probably not be portable (unless you write it yourself, then you can choose to make it portable).
I'm not sure if it is possible with mono, but WIN32 API calls will definitly not work ;)

Subversion Client-Side application [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Which standalone Windows GUI application do you recommend for use for accessing a Subversion repository?
Edit: A lot of people are mentioning Tortoise, however I am looking for an application not a shell extension. Also people are questioning my reasoning behind not wanting to use a shell extension. In our environment we rather interact with the repository (when not using an IDE plugin) through a management application and not navigate the files through Windows Explorer.
Standalone Clients
For total stand alone Synchro SVN is a powerful and cross platform solution. It looks like the most native application on each of the platforms.
The Subversion website includes a listing of other standalone SVN Clients (most are cross platform). [Copied list below from http://subversion.tigris.org/links.html#clients]
eSvn - cross-platform QT-based GUI frontend to Subversion
http://sourceforge.net/projects/esvn
FSVS - fast subversion command-line client centered around software deployment
http://fsvs.tigris.org/
KDESvn - A Subversion client for KDE
http://www.alwins-world.de/wiki/programs/kdesvn
QSvn - A cross-platform GUI Subversion client
http://ar.oszine.de/projects/qsvn/
RapidSVN - A cross-platform GUI front-end for Subversion
http://rapidsvn.tigris.org/
RSVN - Python script which allows multiple repository-side operations in a single, atomic transaction.
https://opensvn.csie.org/traccgi/rsvn/trac.cgi/wiki
SmartSVN - A cross-platform GUI client for Subversion
(Not open source. Available in a free and a commercial version.)
https://www.smartsvn.com/
Subcommander - A cross-platform Subversion GUI client including a visual text merge tool.
http://subcommander.tigris.org/
SvnX - A Mac OS X Panther GUI client.
http://www.lachoseinteractive.net/en/community/subversion/svnx/
Syncro SVN Client - Cross-platform graphical Subversion client.
(Not open source. Free trial versions available for Mac OS X, Windows and Linux.)
http://www.syncrosvnclient.com
WorkBench - Cross platform software development GUI built on Subversion written in Python
http://pysvn.tigris.org/
Versions - A GUI Subversion client for Mac OS X.
(Not open source; requires commercial license.)
http://www.versionsapp.com/
ZigVersion - a Subversion Interface for Mac OS X. Aims to design an interface around the typical workflows of programmers.
(Note that this is not open source.)
http://zigversion.com/
Integrated Clients
TortoiseSVN is the best general use system [An integrated system is not standalone - Thanks Martin Kenny]. It integrates itself into Windows Explorer (You can use it in explorer or any shell dialog) so it works extremely well and gives you the full power of SVN.
Ankhsvn is a good solution that integrates into Visual Studios (Except Express Editions).
SVN Notifier monitors your repositories and will notify you when anything changes. It integrates with TortoiseSVN to show you diffs and commit logs. Very handy when working in a team environment.
TortoiseSVN
From their website:
A Subversion client, implemented as a windows shell extension.
TortoiseSVN is a really easy to use Revision control / version control
/ source control software for Windows. Since it's not an integration
for a specific IDE you can use it with whatever development tools you
like. TortoiseSVN is free to use. You don't need to get a loan or pay
a full years salary to use it.
You can try to use SmartSVN - https://www.smartsvn.com/
Can you explain why TortoiseSVN doesn't work for you? That would help us figure out what you really need in an application.
Combine TortoiseSVN with Windows Explorer and you've got a great tool, and then pickup VisualSVN if you want something to integrate with Visual Studio.
As a shell extension, I guess it's not technically a stand-alone application, but +1 for TortoiseSVN, nevertheless.
I'd recommend TortoiseSVN to get started with (basically, it adds SVN related contextual menus to explorer), but it can be shockingly memory hungry.
I generally use it when I need to, but also make use of the very clean and usable command line tools subversion comes with and Subclipse as part of Eclipse.
The one and only tortoiseSVN!
It is integrated in Windows Explorer, you invoke it with a right click. All commands are under the TortoiseSVN menu, except for frequently used commands such as update, commit or diff (it's configurable).
For some reason, the SVN proterties are located in a tab in the Properties menu, not in the TortoiseSVN menu. It makes sense, sort of, but it took some time getting used to it.
TortoiseSVN is excellent, but I only realised it was awesome when I moved to a Mac (where Tortoise is not available) and tried to find a decent tool. Nothing comes close.
If you don't like shell extensions TortoiseSVN can be used as an application through its handy automation interface - one executable several command arguements.
See TortoiseSVN Manual
Each command raises a modal dialog for a specific task.
For total stand alone Synchro SVN (60$) is one of the nicest looking and full featured ones. It is cross-platform (Win, Linux, OSX).
I use PHPStorm from JetBrains
It can be used in MAC or WIN PC environment. It has internal subversion/git/mercurial tool.
though you do have to pay for it ($50) they have 30 day fully functional trial.
SmartSVN is nice if you want a client that doesn't integrate with Explorer and is instead a standalone app. (Although I think later version offer an Explorer integration as well.)
Memory and disk IO can be a problem with TSVNCache, which manages Tortoise's icon overlays. You can fix it by putting your checkouts in one or two directories and making the cache process only look at those directories, rather than your entire drive.
See this link for instructions.

Resources