SSU Development Thread (2.0 to 3.0)

[n72.75]

Me too.

Face has been maintaining a SSU repo on Bitbucket (https://bitbucket.org/face/ssu), although it doesn't seem to have been updated in a while. If we do want to dump Sourceforge, this might be the simplest option.

Git? or Create a Svn repo elsewhere like OHM. Is that a feature we'd want to add to OHM.

 

[Urwumpe]

Git? or Create a Svn repo elsewhere like OHM. Is that a feature we'd want to add to OHM.

That would be the optimal solution.

 

[DaveS]

That would be the optimal solution.

So maybe we should send a PM to Vash to see if this would be possible.

 

[Face]

Me too.

Face has been maintaining a SSU repo on Bitbucket (https://bitbucket.org/face/ssu), although it doesn't seem to have been updated in a while. If we do want to dump Sourceforge, this might be the simplest option.

It's 3 weeks behind, but I can update it as soon as you guys need it.

---------- Post added at 12:36 ---------- Previous post was at 12:33 ----------

Correction: my local repo is only 3 weeks behind, never pushed that to Bitbucket. Doing it now...

 

[DaveS]

It's 3 weeks behind, but I can update it as soon as you guys need it.

The problem is not having an updated repository but rather one that we can actually check dev stuff into. Without one, we can't check in bug fixes so any talk of a public release is moot as we can't merge all of our fixes into one common location.

 

[Face]

The problem is not having an updated repository but rather one that we can actually check dev stuff into. Without one, we can't check in bug fixes so any talk of a public release is moot as we can't merge all of our fixes into one common location.

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.

 

[GLS]

SF update:

#SourceForge mailing list services online. Work continues 24x7 on file upload, project web, SCM services. Next full update today (7/22).

 

[Urwumpe]

SF update:

Hopefully.

 

[GLS]

The promised full update here.

SourceForge Allura Subversion (SVN) service – offline, filesystem checks complete, data restoration at 50%. Restoration priority after Git and Hg services. ETA TBD, Future update will provide ETA.

I'd say we will have to wait at least 2 more days... :compbash:
Meanwhile I'll probably start writing code in napkins. :facepalm:

 

[Face]

The promised full update here.

I'd say we will have to wait at least 2 more days... :compbash:
Meanwhile I'll probably start writing code in napkins. :facepalm:

Centralized version control is often a single point of failure. My advice would be to migrate away from it as soon as possible.

 

[DaveS]

Centralized version control is often a single point of failure. My advice would be to migrate away from it as soon as possible.

So what is your recommendation as far as version control is concerned? We have to have something that allows use to work on a common base.

 

[Urwumpe]

Centralized version control is often a single point of failure. My advice would be to migrate away from it as soon as possible.

:rofl:

Sorry, but there is always a single point of failure somewhere. Without a central master repository, most open-source projects would fracture.

A decentral version control would mean that you can stay disconnected from the master for a long time - but when you are about to release, any decentral release process is only an emergency solution.

 

[Face]

:rofl:

Sorry, but there is always a single point of failure somewhere. Without a central master repository, most open-source projects would fracture.

A decentral version control would mean that you can stay disconnected from the master for a long time - but when you are about to release, any decentral release process is only an emergency solution.

Well, if your current dilemma is not teaching you a lesson, I sure can't do that. Stick to your guns, I guess.

---------- Post added at 22:37 ---------- Previous post was at 22:32 ----------

So what is your recommendation as far as version control is concerned? We have to have something that allows use to work on a common base.

My recommendation is Mercurial, which should not come as a surprise. I use it privately and at work. At work we used various workflows, from trunk-based (like you do with SVN) to feature branches (what many Git users do).

I would continue with trunk-based in your case, just with a DVCS. This way you never have to worry about such a situation again.

 

[Urwumpe]

Well, if your current dilemma is not teaching you a lesson, I sure can't do that. Stick to your guns, I guess.

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

(In pictures: We have the flood 2 meters high in and around the house. By offering us a small decentral pump, it does not get better now. We still need to wait first for the water to go away and then we still need to make decisions to avoid this happening to our house again).

Also, more pragmatically: Name one popular open-source project that operates without a central master repository. Just one.

In many bigger projects, you even have CI servers. Centrally. Of course you need one central instance for quality assurance and release management.

And it makes a big difference, if this central master repository is on a properly maintained server or on a workstation without backup.

 

[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?