Git really sucks when people are working on code in logically close proximity or the same code. Lots of messy conflicts leading to reversion issues. We are thinking of moving to Apache Subversion instead. Any observations regarding Xojo compatibility would be welcome.
1 Like
Subversion clients for the Mac really are out of fashion. There is Cornerstone. It’s a full subscription app. The website boasts the app now has 10.15 support. I’m also using XVersion which costs 15$. But the support is non-existing.
Never had any problems with conflicts.
Thanks Beatrix. We are on Linux and are looking to self-host.
I’m using an older version of Cornerstone (2.7.18), which is 64bit and dates from before their switch to requiring subscription. It works very nicely under Mojave.
The hosting is not the problem. Is there a good SVN client for Linux?
I personally think Subversion sucks more in the areas you’re concerned about.
5 Likes
Why? They say you can put permission on folders and optionally lock code while editing. Git is too open for that kind of control unless you split projects across multiple repositories, and where’s the version control in that?
Do you and your colleagues work in your own branches or on the same branches simultaneously?
2 Likes
In theory we should be in our own but in practice it means doing a 3-way merge even with only two people. Thant’s when Git works as advertised.
I’ll just throw in here with the fact that CVS still works as expected. You do have to BYO for macOS, but for Linux, it’s as easy as “sudo apt install cvs” or “sudo dnf install cvs”.
The problem with Git is there is no single source of the Truth. It’s all relative to what the project owner believes is the Truth at merge time. The debate we are having with Subversion is what happens with offline work? I would say the same thing but the WAN is always on these days so we are stupid to adopt a manual merge technology if we can avoid it, even if that’s what the herd is doing.
Yes Tim, Apache market Subversion as CVS+
Git seems to me a breeding ground for slow motion source code race conditions.
1 Like
Checked GitLab out. Part of the locking is closed source subscription based.
We typically don’t have problems, or just minor problems that are easily resolved.
Each developer works on their own branch, then, through a Pull Request, merge that branch into the develop branch.
When a developer sees changes to the develop branch, they merge those changes into their own branches and resolve any conflicts there. This is done before merging back into develop so there will be no conflicts during that merge. The develop branch is the source of truth.
The only time two developer have the same branch checked out is during peer programming or testing, and even then only one is designated to make changes.
There are times when two developers have changed the same section of code, but there is no race because one will have merged into the develop branch first, and it’s up to the second developer to resolve any conflicts.
I offer this in hopes that something in it will give you an idea on how you might adjust your process to make things smoother.
6 Likes
I don’t really have much to add since Kem covered it perfectly. This is the workflow you should be using.
Thanks Kem and Thom, that helps my understanding greatly and I’m sure will be of assistance to all reading this post.
The assumption with this workflow is that any Dev can be a source of the Truth at merge time. That is not the case for us because some of our stuff is the result of experimentation while others is based on experience of how third party services act which itself can be the result of some trial and error.
And as part time devs the system is too big to hold in our heads all at once anyway. (It’s an asynchronous services-based architecture.)
For these reasons I’m wondering if a more synchronous style of code management at least might make life easier.
I like to throw in to try the app SmartGit. Works on all 3 big platforms and does, IMO, a good job at visualizing and managing merges and conflicts.
For instance, it has its own merge viewers that help merging changes on the same file from two sources or branches.
Hi, git, subversion or whatever won’t solve the problem.
You’ll need a clear architecture , and a lot of discipline.
What helps :
Put a sync composition file in between.
Have a look at Using depot_tools - The Chromium Projects ( gclient ).
Benefit: everybody is working on the same stuff, and there a clear rules, who is allowed to update it …
HTH Rainer
… now a lead integrator again …