Distributed version control systems (DVCS)

[joevenzon]

I think the user-oriented "encourage forking" paradigm aligns very well with the idea of this project being a sandbox for free experimentation by developers.... Joe, any thoughts on that?

Yes, I like it.

Also, fudje gets a million points for the obscure Garbage reference.

[fudje]

Sadly because I also misquoted in the first place, I also lose a million points I fixed it now

[fudje]

My take on possible workflow. First up is a view on how the main tree could be managed:

http://fudje.blogspot.com/2010/12/hypoth...w-for.html

[thelusiv]

Great article fudje. That workflow looks fairly simple and straightforward. Would you be interested in adapting this to a wiki-friendly format to put here perhaps? http://wiki.vdrift.net/Git_workflow

...for a DVCS I personally do not see the wisdom in differentiating between development and staging at this level, however this path has the support of consensus.

You missed that part of the discussion during the IRC meeting, please share your views on the topic and we can continue discussion.

[fudje]

That's more of an "If I was running the show..." kind of comment, however: My point of view comes from the fact that with a dvcs you can generally afford to shut down the main tree during the bugfix phase of a release, as each developer's branch can be accessible to every other developer, allowing for continued testing during this time. On the other hand, if you approach a system with the thought of a staging branch being a good idea, you probably ought to have one. It's not a bad thing, merely something that can be omitted if you don't mind allowing development to be completely decentralised during this period

The article and its follow up that is currently in the works are more supposed to be food for thought. Certainly the part that deals with developer trees should be more interesting to the wiki anyway.

[joevenzon]

My point of view comes from the fact that with a dvcs you can generally afford to shut down the main tree during the bugfix phase of a release, as each developer's branch can be accessible to every other developer, allowing for continued testing during this time.

I would actually be fine with that, especially since we'll have a "current release" branch available for anyone who needs something really stable.

[thelusiv]

I went ahead and created an Organization for VDrift on github.com. I also created a single repository. I don't plan on populating it with anything meaningful until when I do this release, but figured I could go ahead and start setting up the account, building the Teams, and adding items to the issue tracker, since no one has voiced any opinion against using github.

https://github.com/VDrift

fudje, I look forward to reading your next article. Perhaps you could also treat the case of not using a staging branch? I think if it's not strictly necessary, then let's avoid the extra complexity; it will just add an extra step to releasing...

[fudje]

Without the staging branch

http://fudje.blogspot.com/2010/12/hypoth...or_21.html

[thelusiv]

Thanks for the in-depth explanation fudje. I am still a little unsure whether to use a staging branch or not. It seems like it would not be so much extra work or complexity, nor does it have particularly great advantages. Maybe just for clarity purposes, we should start out using one, and then drop it later, if it seems superfluous. (...or maybe we should just start out without it for simplicity and add it later if it's needed?) :?

[fudje]

As I said before, if it's a question, you should probably use one. An extra branch isn't very much extra complexity at all, it has essentially no cons.

[thelusiv]

OK, well in that case let's just go ahead and use one, and ditch it later if we feel it's unnecessary.

[fudje]

Took a bit longer than I expected (and, I guess, promised), but here's part II of the workflow, or the bit for developers who are not "collaborators".

http://fudje.blogspot.com/2011/01/hypoth...w-for.html