Quote: Original post by Yann L

Quote: Original post by Dmytry
In fact, I'm getting distinct impression that you just speculated this up, with "This was the main problem I experienced when working with distributed systems." never happening.

You know, if you really believe this, then I think that any further discussion with you is pointless.

actually I'm 90% certain in that.
It took me pointing an advantage of DVCS to get you thinking in direction how it could be abused. I agree that scenario is a possibility, though, due to my limited experience, I never seen that ego trip forking mayhem happen even though open source projects seem to be plagued with ego issues to much larger extent than commercial projects.

Quote: Original post by Dmytry
due to my limited experience,

Oh the irony...

Let's end this. This is counterproductive to this thread.

I like SVN but have 3 problems with it:

1) There is no "rename" or "move" operation. Instead it's done with a delete and a create operation (or maybe copy and delete). The result is, that if you have two branches, and you want to merge changes of branch A into branch B, and in branch A file X renamed to Y, while in branch B file X was changed, after the merge, the changes made to file X in branch B are gone. With a true rename or move operation, it would have been able to merge Y with X and thus merge in a much better way.

2) When making a tag or branch of a certain revision, if there are externals, it should be possible to make it automatically recursively remember all current revisions of the externals, their externals, and so on. Currently, a tag isn't always a true tag of the current state if there are externals that changed.

3) There's no operation to "un-checkout" or "un-version" a local folder, in other words, to remove all ".svn" folders while keeping the rest. It would have been noble to add this simple feature in SVN.

I think if those 3 were solved, SVN, which already is great, would become "unbeatable".

Well ok, I've also got some other problems with it, like the fact that there are very many files in the .svn folders, making it very slow to do file operations on directories with SVN code in them, and, the fact that too often I have to do a "clean up" because things become corrupt.

P.S. off topic, looking at the "warning level" on some users in this thread: I hope having a discussion with a moderator doesn't give you a warning level!! :)

Quote: Original post by Lode
I like SVN but have 3 problems with it:

Agreed on these points. Especially the first one is very serious, and many people constantly complain about this missing vital feature. The new version supposedly alleviated the problem somewhat, but I haven't tried it yet. Point number 3 is just stupid - it would take the SVN developers five minutes to implement this very useful feature.

Another thing that would be good, but much more difficult (and impossible in some cases) to implement is to entirely remove the history of a specific file in all revisions, within the entire repository.

Also, a big problem with very large (and imaginary, according to some people [wink]) SVN repositories is that they tend to become really slow. RAID and a good CPU helps, but this doesn't hide the fact that SVN's DB system is not really scalable. I've been using FSFS. Maybe switching to Berkeley DB would help, but it's supposed to be very unstable and prone to data loss. Our solution at this point was to split up the project into separate repositories, which was pretty straightforward due to the plugin-based nature of most projects. But still, this is not optimal.

Quote:
P.S. off topic, looking at the "warning level" on some users in this thread: I hope having a discussion with a moderator doesn't give you a warning level!! :)

Of course not. You will never get a warning for having an argument with a mod, or anyone else for that matter. You'll get a warning when you have a history of insulting others during your 'arguments'. Anyway, Dmytrys' warning level has nothing to do with this particular thread, and it's certainly not from me.

Speaking of merging in DVCS.
Merging seems kind of counter-intuitive at first; if you have some 'central' repository, all resolution happens when you merge 'central' onto personal, not when merging personal onto 'central'. Fortunately, you can merge central (or any other) repository onto personal as often as as you like; even when your changes would break everything if you were merging or committing them into central.
If I merge other's work into my often, I rarely ever have to resolve anything by hand. If I rarely merge, I have to do more merging work total because there's more conflicts requiring manual resolution. Same goes for getting my work merged into central. It is matter of my convenience.
You can create merge mayhem for yourself, of course. But you always can if you want to; this is no reason for choosing more limited system.

Lode's offtopic: yea, not related to this thread. Though, if you don't readily buy into people's implicit assertions of their expertness to the contrary to knowledge evident from actual content of post, that could well be taken as insult.

[Edited by - Dmytry on May 24, 2009 12:06:39 PM]

Quote: Original post by Dmytry
The conflict resolution is done when main branch (and relevant sub branches) are merged onto sub-branches during development, which you can do as often as you like. As result, merging of sub branch onto the central repository is conflict-free, as the merge been already done.

That's exactly how I work in SVN as well. You create a branch, work on it, then every few days you merge trunk into your branch. Then when you're finished, you "reintegrate" your branch back into trunk. There's a lot of small conflicts as you merge trunk into the branch, but by the time you reintegrate your branch back to trunk, there won't be that great big conflict that you'd get otherwise...

This operation used to be fairly difficult (requiring use of an external script) in SVN until version 1.5 when they implemented the merge tracking feature. Merge tracking created problems of it's own (of course) but for the most part, it works quite well.

Anyway, as you can probably tell, I've never really used GIT to any great extent. Personally, I can't see the benefit - our team is quite efficient with SVN. The last job I worked at we had ~120 developers with a repository stored in Visual Source Safe, so you can imagine that moving to SVN was like waking up from some horrible nightmare :-)

Quote: Original post by Codeka

Quote: Original post by Dmytry
The conflict resolution is done when main branch (and relevant sub branches) are merged onto sub-branches during development, which you can do as often as you like. As result, merging of sub branch onto the central repository is conflict-free, as the merge been already done.

That's exactly how I work in SVN as well. You create a branch, work on it, then every few days you merge trunk into your branch. Then when you're finished, you "reintegrate" your branch back into trunk. There's a lot of small conflicts as you merge trunk into the branch, but by the time you reintegrate your branch back to trunk, there won't be that great big conflict that you'd get otherwise...

Yea. Works great. git resolves trivial conflicts automatically, so if you're merging properly you rarely ever need to do any manual resolution (don't know about SVN today). At first I was very suspicious about that automatic merging, but I never seen it cause any extra problems.
Also, that makes merging a responsibility of whoever forked.

Quote:

This operation used to be fairly difficult (requiring use of an external script) in SVN until version 1.5 when they implemented the merge tracking feature. Merge tracking created problems of it's own (of course) but for the most part, it works quite well.

I used SVN a while ago, when branching was major pain.

Quote:

Anyway, as you can probably tell, I've never really used GIT to any great extent. Personally, I can't see the benefit - our team is quite efficient with SVN. The last job I worked at we had ~120 developers with a repository stored in Visual Source Safe, so you can imagine that moving to SVN was like waking up from some horrible nightmare :-)

Well, the benefit wouldn't be all that great if team is well used to SVN, I wouldn't say that switch is warranted, unless you're having real problems with svn.
You can still use git just like you use svn btw; if you want you can have some central repository that everyone works with, and forbid people to use each other's repositories (require them to make branches on central, for example).

It is true though that for every thing that one VCS does which other VCS doesn't or which one VCS does better, you can think up a scenario how a poorly managed team might abuse it (e.g. easy branching might lead to too much branching, separate repositories might lead to forking, and so on); some scenarios might be realistic and some be far fetched.
Let me think up scenario of git abuse myself. Project officially uses SVN. All the poorly-managed team's issues speculated up earlier arise anyway because it is almost as easy to clone svn repository with git as to clone git repository.[grin]

[Edited by - Dmytry on May 25, 2009 7:58:59 AM]

To go back to the original discussion, I've switched to Bazaar for my personal projects after evaluating several different possibilities.

Bazaar has 3 important advantages over other systems:

1. It works without a server. You can create a repository and commit over simple ftp or a file:/// uri (*great* for USB sticks). A server is available to improve performance, but it's optional.


2. Its command set is intuitive (unlike, say git). It also comes with a Windows GUI (unlike, again, git).


3. You get all the advantages of DVCS (ease of branching, local commits, yada yada), but you can still use it with the SVN model (and, indeed, it offers the exact same commands).

Its main disadvantage is its lack of IDE integration, but fortunately both the GUI and the commandline tools are usable.

SVN has become the de-facto standard of source control systems. Easy to setup, easy to use, relatively flexible, good tools. Nowadays, Anything less than SVN is considered "unusable" and anything more is nice, but not strictly necessary. There will come a day when SVN will be replaced by something better (probably decentralized or at least with decentralized capabilities), but until then SVN is a good default answer.

Suggestion: use SVN and when you grow comfortable with branching and merging try out Bazaar or another decentralized system.

@Yann L: do you not use feature/version/vendor branches while developing your project? If you do, a DVCS can only improve your workflow (other considerations aside, like IDE integration). Even something like git-svn used locally (or bzr-svn, altough I doubt the latter can cope with a codebase that brings SVN to its knees) provides capabilities not available to SVN (more granular commits, bisect, weave, etc).

Edit: grammar, spelling mistakes, I must've been drunk.

[Edited by - Fiddler on May 25, 2009 12:58:04 PM]

Quote: Original post by Fiddler
@Yann L: do you not use feature/version/vendor branches while developing your project?

Major version branches, yes. But since our software is heavily plugin based, all minor feature revisions, special features and vendor dependent modifications go into separate plugins.

Each plugin project gets its own independent repository, and is only dependent on the SDK folder of the main version branch it is built against. This works pretty well with SVN. It helps to keep repository sizes down the critical mass, and it allows us to balance SVN traffic over multiple servers without sync issues.

Some of these plugin features can eventually be merged into the main branch on a new version of the software. No conflicts can possibly arise from these merges, since all plugins use an independent and fixed API between the main branch and between each other. So it's basically just new files added to the branch.

About Bazaar, I have briefly looked at it in the past, and indeed it seemed interesting. I haven't yet have the opportunity to try it on a real project though.

Was Dmytry always so volatile? We've both been members for several years and when we both used to post in the Physics forum a lot (assuming I am not mixing up another member) I remember him being very level-headed and all about the problem-solving. This thread just seems full of anger and even bitterness, as much as you can read emotion through forum posts.
Have I missed some huge flame-war where someone said something about someone else's mom?!