|
It was also handy back in the days when only single array indexes existed and you wanted dual indexes because everything mathematically matched up really handily without taking extra steps.
for (i = 0; i < 10; i++)// Not at all like the format of older languages!
{
for (j = 0; j < 10: j++)
{
ind= i + j * 10;
val[ind] = some value
}
}
Or the other way around, find the two indexes from the current index:
for (ind = 0; ind < 100; ind++)
{
j = ind/10;
i = ind - (j * 10);
}
|
|
|
|
|
|
Seriously? Clean this up or it'll get deleted pretty quick: at present it is meaningless garbage.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
|
|
|
|
|
|
I don't trust it.
Two of us have been working on the same file today, so we agreed he would check his changes in first and I would update mine, merge and commit the merge. I get the go ahead to update, update tells me correctly that the exact same file we've worked on is conflicted. I look at the file. no "mine" or "r.6271" markers anywhere to be seen, but a load of interface implementations are missing. I update again, to no avail. I stubbed out the interface implementations, compiled, ran all my tests and tried to commit only to be told that my file is out of date and needs updating before I can commit so I update again, and hey presto, a handful of marked conflicts in the same file. Nobody else has committed anything in that time. WTF?
Last week our build server failed to get the externals we'd set up on a repository, even though a local update got them all. Cue hours of digging around instead of actually being productive.
I really hate SVN.
|
|
|
|
|
Quote: I really hate SVN. I have used SVN, Source Safe, and TFS source control and none have been perfect when multiple people work on the same file at the same time. I have had issues with all of them.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
ryanb31 wrote: I have used SVN, Source Safe, and TFS source control and none have been perfect when multiple people work on the same file at the same time.
We've had people edit the same file at the same time using SVN without problems... we usually avoid conflicts though, but if they happen they've always been marked properly. I have other issues with svn though, like the confusing and varied ways to branch and merge branches, though once you have the proper steps figured out it goes ok.
What I find odd is having multiple people editing the same section of the same file simultaneously, seemingly intentionally. Why would you do that? That's bad communication or organization. Whenever it's happened to us it's been an accident or as a result of bad communication/misunderstanding over who was doing what.
If you're using tools that automate code generation, e.g. resource editors, then it's hard to coordinate two people doing it, so two people shouldn't do it simultaneously. I know it was an SVN bug in this case, but even when SVN does things correctly with conflicts it can be a nightmare to sort out.
Look at me still talking when there's science to do
When I look out there it makes me glad I'm not you
|
|
|
|
|
Quote: but even when SVN does things correctly with conflicts it can be a nightmare to sort out. True. Often the problem comes when someone has checked a file in several times since the other person checked it out. For some reason it struggles on merging.
I can't imagine having to write the code for a source control tool so I am grateful for what there is.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
There must be a way to lock the file to keep others from editing it. I believe that TFS has this ability.
|
|
|
|
|
James Lonero wrote: There must be a way to lock the file to keep others from editing it. I believe that TFS has this ability.
SVN didn't used to have that ability, but it does now.
Look at me still talking when there's science to do
When I look out there it makes me glad I'm not you
|
|
|
|
|
Have you tried Git? I've not used it, and from what I hear it can be pretty awkward at times. But it must have some merit considering it's popular use.
.-.
|o,o|
,| _\=/_ .-""-.
||/_/_\_\ /[] _ _\
|_/|(_)|\\ _|_o_LII|_
\._. |\_/|"` |_| ==== |_|
|_|_| ||" || ||
|-|-| ||LI o ||
|_|_| ||'----'||
/_/ \_\ /__| |__\
|
|
|
|
|
Lloyd Atkinson wrote: But it must have some merit considering it's popular use.
One word: Bieber
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
|
|
|
|
|
Git is the worst source control system I've ever worked it. Including VSS.
|
|
|
|
|
It depends: having a completely distributed source control system is gold, for me.
Which happens also to be blazingly fast, btw.
Oh well, whatever.
|
|
|
|
|
Reading this forum guidelines at the top, I feel this is posted in the wrong forum section.
Just saying!
|
|
|
|
|
I like Mercurial[^]. Never tried merges or anything (I am the only one using my repos), but apparently Mercurial can handle things like this just fine.
There is also Bazaar[^], which I have never used, but it looks like a very good version control system. Very well documented (from what I have seen).
I have tried Git, but never really got used to it.
EDIT: tries != tried
Gryphons Are Awesome! Gryphons Are Awesome!
|
|
|
|
|
Improve your process.
It's always best to avoid merges no matter how good your tool is.
|
|
|
|
|
I've used SVN a lot...and had many more problems than success with merges (although the later versions are getting better).
I've also used mercurial a lot...and can count the number of merge conflicts I've had on the fingers of one hand. Fundamentally, a DVCS like mercurial or git has much better theoretical underpinnings than SVN. Branches are treated as alternate repositories, NOT just as other sub-trees in a file system.
So, anyway - use mercurial (or git, I guess, I just have a prejudice against it ), life'll be that much easier...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|
Stuart Dootson wrote: a DVCS like mercurial or git has much better theoretical underpinnings than SVN. Branches are treated as alternate repositories
I don't get that. SVN uses one repository, Mercurial/GIT use many repositories - if anything that should increase the number of required merges, not decrease them, no?
|
|
|
|
|
I stated that badly, I think. What I meant really, is that when you branch in SVN, you're effectively copying the trunk (or whatever branch you're on) to a new location in the SVN repository (although, of course, it's all done with links, really). With Mercurial or Git, you're just adding a label to the current state of the repository that says what branch the revision is at the tip of.
And to be honest, the number of merges doesn't really matter so much - it's how well the system can track the changes you've made that's at issue.
With SVN, when you do a merge, the merge code in SVN looks at what files each directory sub-tree contains and tries to merge their current states.
With Mercurial (or Git), when you do a merge, the merge code looks for the nearest common ancestor changeset between the two revisions you're merging, then (in effect) replays the changes that give the 'other' revision onto the revision you're merging into. And this extends to other repositories - Hg/Git can easily find common changesets between different repositories, because each changeset is identified by a hash (SHA-1, IIRC). The best description I can find of why DVCS's are better at merging than a centralized VCS like SVN is in Eric Sink's book Version Control By Example[^]:
- They’re built on a DAG (see Section 4 in Chapter 4). Merge algorithms need good information
about history and common ancestors. A DAG is a better way to represent that kind of information
than the techniques used by most centralized tools. - They keep the developer’s intended changes distinct from the merge she had to do in order to get
those changes committed. This approach is less error-prone at commit time, since the developer’s
changes are already cleanly tucked away in an immutable changeset. The only thing that needs to
be done is the merge itself, so it gets all the attention it needs. Later, when tracking down a
problem, it is easy to figure out if the problem happened during the intended changes or the merge,
since those two things are distinct in the history - They deal with whole-tree branches, not directory branches. The path names in the tree are
independent of the branch. This improves interoperability with other tooling.
To show that, try this:
1) Create an empty repository and create a file called a on the trunk (in SVN) or default branch (in Hg).
2) Create a branch called test_branch and make it the current branch.
3) Rename the file a to b (using svn rename /hg mv ).
4) Merge test_branch back into the trunk/default branch.
With SVN (version 1.7.8), this resulted in two files on the trunk, a and b . With Hg, the merge resulted in one file on the default branch - b . Now, it seems to me that Mercurial's done the right thing because it tracked the changes that I'd made, *not* the current state of a set of files...
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
CodeProject MVP for 2010 - who'd'a thunk it!
|
|
|
|
|