SSU Development Thread (2.0 to 3.0)

[Face]

Our current dilemma? Sorry, but I think that you are getting dogmatic without offering a real alternative to the real problem. We can agree that a DCVS would make a lot of the situation better. But it will not fix the dilemma of making it hard to release right now

The only one getting dogmatic is you. At least you agree that a DVCS would make the situation better, which is a real alternative to one where developers want to write code on a napkin.

 

[Urwumpe]

The only one getting dogmatic is you. At least you agree that a DVCS would make the situation better, which is a real alternative to one where developers want to write code on a napkin.

Currently we can write a lot of code on notebooks. Which at least starts the same way as the napkin. But at one point, we will have to merge and we will have to see together, that the merged version is passing tests.

So... I know how hard this gets with DCVS with all developers in the same room at the same time, while master repository is lost during translation. Don't tell me about how complex we can make it to solve the problem with four persons in different places at different times zones. Its not trivial.

Sorry, but total decentralism is dogmatic in the situation and if the alternative would be using diff and patch again, we can talk about pushing and pulling over the whole globe.

 

[GLS]

I don't know half of the systems you are talking about, so excuse my opinion.:blush:
I'd say the current system is good... except there's no backup for situations like this. If there were 2 repositories (a main for "normal use", and a backup that would shadow the main and also serve as a fallback in case the main went dead), a situation like this wouldn't stop us from continuing development. Speaking for myself, if there's a system like this, that we can use, I'd be happy.

 

[Face]

Currently we can write a lot of code on notebooks. Which at least starts the same way as the napkin. But at one point, we will have to merge and we will have to see together, that the merged version is passing tests.

Yes, you can write code. But can you version control it with regards to your repository? I think not.

With Mercurial (and many other DVCS, FWIW) sharing code is as easy as starting the built-in HTML web-server and telling your colleagues to just push/pull to/from there until the master repo gets online again. Been there, done that.

So... I know how hard this gets with DCVS with all developers in the same room at the same time, while master repository is lost during translation. Don't tell me about how complex we can make it to solve the problem with four persons in different places at different times zones. Its not trivial.

Yeah, I have my anecdotes, too. I know how easy this gets with Mercurial with all developers in the same room at the same time, while master repo is lost during translation. I won't tell you how simple you can make it to solve the problem with 15 persons in different places at different time zone. It was trivial.

Sorry, but total decentralism is dogmatic in the situation and if the alternative would be using diff and patch again, we can talk about pushing and pulling over the whole globe.

The only one talking about extreme measures is you. I never said that total decentralism is the key. This dogma is assumed only in your writings. You are the one dealing in absolutes here ("there is always a single point of failure", "any decentral release process is only an emergency solution"), whereas I just wrote that centralized version control is often a single point of failure. See the difference between "always" and "often"? The former one is a dogma, the later a statement of observation.

Another extreme is of course to fall back to diffing and patching. Don't know why you want that now out of a sudden.

And to be honest, I can't care less. As I already said: stick to your guns if that is working for you. I only joined the discussion because your project seemed to be in need of some help, and because my nick was mentioned. Looks like you don't like that, so I'll stop it.

 

[SiameseCat]

I see. If you use Mercurial, I can give you access to it, of course (or you simply clone it). But I guess you want to stick to SVN, so this is no solution.

I can't speak for anyone else, but I'd prefer Mercurial to SVN.

---------- Post added at 10:10 PM ---------- Previous post was at 10:03 PM ----------

I don't know half of the systems you are talking about, so excuse my opinion.:blush:
I'd say the current system is good... except there's no backup for situations like this. If there were 2 repositories (a main for "normal use", and a backup that would shadow the main and also serve as a fallback in case the main went dead), a situation like this wouldn't stop us from continuing development. Speaking for myself, if there's a system like this, that we can use, I'd be happy.

If you haven't used a DVCS (like Mercurial or Git), it works by having a local repository on your computer, as well as external repositories (like our Sourceforge repository). So you can make commits locally, and then push the local commits to a central repository later. Of course, the rest of us can't see your commits until you push them to the central repository.

 

[GLS]

If you haven't used a DVCS (like Mercurial or Git), it works by having a local repository on your computer, as well as external repositories (like our Sourceforge repository). So you can make commits locally, and then push the local commits to a central repository later. Of course, the rest of us can't see your commits until you push them to the central repository.

No, I never used anything but SVN. The local repository thing seems interesting as a backup to the server, which is something I wanted to get for sometime now... any idea how big the history of SSU is?

 

[DaveS]

No, I never used anything but SVN. The local repository thing seems interesting as a backup to the server, which is something I wanted to get for sometime now... any idea how big the history of SSU is?

I believe it goes all the way back to the very start of SSU, back in 2008 before SSU was SSU and Space Shuttle Deluxe.

 

[Urwumpe]

I believe it goes all the way back to the very start of SSU, back in 2008 before SSU was SSU and Space Shuttle Deluxe.

Yes. Also that was at a time when Mercurial and git had still been pretty exotic (git and Mercurial started development in 2005, I had not seen a stable windows client of any of them before 2010)

I would prefer git over Mercurial in that question, simply because git support is now standard in Visual Studio and also supported by other Microsoft development tools. For Mercurial, we would need third-party tools like VisualHG. (And I have more practical experiences in using git with the internal Visual Studio client)

By the features, Mercurial and git are both almost identical, there is only the small conceptual difference that Mercurial operates by change sets, while git uses snapshots. Practically, you only notice the difference by the two in extreme conflict situations.

---------- Post added at 06:25 PM ---------- Previous post was at 05:46 PM ----------

Another extreme is of course to fall back to diffing and patching. Don't know why you want that now out of a sudden.

Look, lets make it much easier. You have no problem here at all. We have it. The milk is already poured here and your friendly suggestions from the sideline how much better we would have had it, had we been using your favorite tool, are not really helping us right now. But you sure feel like a hero about your hindsight having 20/20.

Also, what you call extremes are normal situations. It is not like what I describe there does not happen except in Roland Emmerich movies. If you tell me that you never had such problems in development to deal with, maybe you never had the problem that the real world consists of you knowing many better tools, but you having to stick to the good enough for economic reasons. Or you had been extremely lucky. Even having Mercurial did not prevent problems (Some bugs in TortoiseHg even caused their own problems back then)

And trust me: Diff/Patch is not the most low-tech solution to get code changes into the master instance.

Extreme would be using printed sources with text marker highlights of the changed statements and mail.

---------- Post added at 08:47 PM ---------- Previous post was at 06:25 PM ----------

No, I never used anything but SVN. The local repository thing seems interesting as a backup to the server, which is something I wanted to get for sometime now... any idea how big the history of SSU is?

It is more than just a back-up for a central master repository. You can for example also create local branches in git, which allow you to work locally on stuff without somebody else ever seeing it, which makes feature branches less painful than they are in SVN.

Also, since you not only commit or revert changes to your local repository, but also have to push/pull changes from outside (master or any other instance), you have a completely different way to organize your development work.

You can't make people better developers with git (Some still only sync their changes shortly before release and then wonder why they need weeks for fixing the collisions), but if you plan to operate agile and especially if you are interested in continuous delivery, git is a great tool.

 

[Donamy]

I thought Face was just trying to be helpful. Here I thought we were close to a release, boy was I mistaken.

 

[DaveS]

I thought Face was just trying to be helpful. Here I thought we were close to a release, boy was I mistaken.

Well, with SVN still down none of us can add our bug-fixes to the release pack. So all hinges on when SourceForge gets to restoring SVN services.

Edit:
Also none of Face's suggestion solves the fact that we don't have a common place to pool our work.

 

[GLS]

It is more than just a back-up for a central master repository. You can for example also create local branches in git, which allow you to work locally on stuff without somebody else ever seeing it, which makes feature branches less painful than they are in SVN.

Also, since you not only commit or revert changes to your local repository, but also have to push/pull changes from outside (master or any other instance), you have a completely different way to organize your development work.

You can't make people better developers with git (Some still only sync their changes shortly before release and then wonder why they need weeks for fixing the collisions), but if you plan to operate agile and especially if you are interested in continuous delivery, git is a great tool.

I've read somethings today about DVCS and I'm trying to wrap my head around it. I think it might be possible to avoid the users getting isolated from each other (due to each having his/hers repository) by having a policy (probably unenforceable) of doing commits and pushes together, and on the other end having devs trying to keep the local repositories as updated as possible. In a way just using the local repository as a back up, and in situations like this it would allow for some work to continue. I still haven't thought about how the branches would work.

 

[Urwumpe]

I thought Face was just trying to be helpful. Here I thought we were close to a release, boy was I mistaken.

Same was my thought until last weekend. Right now I feel like I am in the wrong project.

---------- Post added at 10:16 PM ---------- Previous post was at 10:11 PM ----------

I've read somethings today about DVCS and I'm trying to wrap my head around it. I think it might be possible to avoid the users getting isolated from each other (due to each having his/hers repository) by having a policy (probably unenforceable) of doing commits and pushes together, and on the other end having devs trying to keep the local repositories as updated as possible. In a way just using the local repository as a back up, and in situations like this it would allow for some work to continue. I still haven't thought about how the branches would work.

Well, you can work like that. But again, this only solves the low-level problems. When we want to do a release, we have to make sure that everybody who has something that must get into the release also pushes his changes to the master branch on the repository that should be reference for the release. It must not be the repository on a central server. But having one single point of contact that is available 24/7 makes the work a lot easier as you can expect.


Also, the branches work pretty much like that: You create a branch locally on your repository. You can keep it like that. Or you can make the branch public, so that it is exchanged when you sync with another repository.

 

[GLS]

Well, with SVN still down none of us can add our bug-fixes to the release pack. So all hinges on when SourceForge gets to restoring SVN services.

Edit:
Also none of Face's suggestion solves the fact that we don't have a common place to pool our work.

I think tomorrow afternoon/night it might be back up. According to the updates there's one more system to be restored and then SVN is next. We should then give it a few hours to allow it to "stabilize" and also to let the initial wave of traffic pass (it will have most/all SVN projects there doing changes and who knows what will happen to the servers). So I'd guess Saturday morning we will be back on business.

 

[DaveS]

I think tomorrow afternoon/night it might be back up. According to the updates there's one more system to be restored and then SVN is next. We should then give it a few hours to allow it to "stabilize" and also to let the initial wave of traffic pass (it will have most/all SVN projects there doing changes and who knows what will happen to the servers). So I'd guess Saturday morning we will be back on business.

AFAIK, the servers are fine. It is the file system that for some reason took a dive and became corrupted. If it had been the hardware SF.net would been 404's and not maintenance/503's.

 

[Urwumpe]

AFAIK, the servers are fine. It is the file system that for some reason took a dive and became corrupted. If it had been the hardware SF.net would been 404's and not maintenance/503's.

Thats not that easy on a bigger infrastructure, since it is a lot different to your local computer. Often you have a multi-tier architecture behind the address. This means, your filesystem servers can still be partially down or in maintenance, while the front-end web-servers still reply and give you 503s, while work is underway.

 

[GLS]

SourceForge Mercurial (Hg) service online
I think SVN is next :woohoo:

 

[SiameseCat]

I would prefer git over Mercurial in that question, simply because git support is now standard in Visual Studio and also supported by other Microsoft development tools. For Mercurial, we would need third-party tools like VisualHG. (And I have more practical experiences in using git with the internal Visual Studio client)

I actually prefer Mercurial over Git for that reason; TortoiseHG is really good, better than TortoiseSVN and anything I've seen for Git. I haven't tried Git in Visual Studio, though.

 

[Face]

Also none of Face's suggestion solves the fact that we don't have a common place to pool our work.

What suggestions? I wasn't even able to suggest something - beyond trying to migrate away from centralized version control - before being attacked for daring to speak up.

As I wrote before: I just joined the discussion because you seemed to be in need of some help, and because my nick was mentioned. But getting ridiculed is certainly nothing that will motivate me to continue it.

 

[GLS]

About the new talkbacks, can we edit the groups directly with this?

	/**
	* \brief Returns a pointer to the group specification of a mesh group.
	* \param hMesh mesh handle
	* \param idx group index (>=0)
	* \return pointer to mesh group specification (or NULL if idx out of range)
	* \note \b MESHGROUP is a structure that contains the components of the
	*   group, including vertex list, index list, texture and material index.
	* \note This method can be used to edit the a mesh group directly (for geometry
	*  animation, texture animation, etc.)
	* \note This function should only be applied to device-independent meshes,
	*   such as mesh templates.
	* \note For device-dependent mesh instances (such as returned by
	*   \ref VESSEL::GetDevMesh) use \ref oapiEditMeshGroup instead.
	* \sa oapiEditMeshGroup
	*/
OAPIFUNC MESHGROUP *oapiMeshGroup (MESHHANDLE hMesh, DWORD idx);
OAPIFUNC MESHGROUP *oapiMeshGroup (DEVMESHHANDLE hMesh, DWORD idx);

Or for us this just to get the data for a group?

 

[DaveS]

Latest SourceForge update: http://sourceforge.net/blog/sourceforge-infrastructure-and-service-restoration-update-for-724/

SourceForge Allura Subversion (SVN) service – offline, filesystem checks complete, data restoration has completed 22 letters (4 remain). This is our current restore priority. We project restore of data to complete by 7/25, to be followed by data validation and restore of service. ETA to follow once I/O performance calculated during data validation.