Which SCC software between Git and Hg should I use?

[honoka]

Tortoise SVN seems to be the most stable, but I prefer to use a distributed SCC system.

Since my boss is impatient and impetuous(probably ADHD because his son has ADHD), I think I can't afford to fiddle with SCC for more than a week.

I read all those threads about Tortoise HG in this forum, but I'd like to give TortoiseGit a shot.

The choice doesn't entirely depend on my preference but would have to be the more stable one.

Which one is more stable?

Should I just stick to Tortoise SVN for stability?

[Onno]

I've been playing around with Mercurial briefly, but went back to TortoiseSVN, both for reasons of stability and convenience. Especially getting Diff/Merge to work nicely with TortoiseHg was a major pain (not unsolvable — see other posts on LavaG — but too much of a hassle in my opinion).

Not sure about TortoiseGit though.

By the way: would there be any specific reasons to prefer a DSCC over SVN? Those SCCs seem to rely (*) quite heavily on merging, which is still a rather messy job with LabVIEW anyway. (Given the binary file format, custom diff/merge tools, and LV's propensity to modify files at will).

(*) Maybe "rely" is not the best word to use here, but they do treat branching/merging as much more of a first-class citizen than SVN — which, for me, would be the most important reason to switch, I guess.

[Antoine Chalons]

I suggest you take a look a the article listed here, interesting comparison between SVN, Mercurial, Git and Bazaar before making a choice.

Hope this helps

[AusTEX]

I've been using Hg via TortoiseHg and really like it so far. I was able, with the help of especially Ton Plomp (thanks again Ton) to get merging working - and it works well. So far I haven't found any downsides to Hg.

[Ton Plomp]

I'm relying on HG. Have never really worked with Git since I'm happy with HG.

Since you don't have the time to dive into the SCC system you want to use I would advice you to go with HG, it's just harder to mess up.

I haven't had stability issues with HG (Workbench).

What are you going to setup as a server? If you have the time (approx. half a day), setting up rhodecode on a linux server is a good idea. It gives you user management and a web-interface beyond the shipped webserver of HG.

Ton

[Jordan Kuehn]

I'm relying on HG. Have never really worked with Git since I'm happy with HG.

Since you don't have the time to dive into the SCC system you want to use I would advice you to go with HG, it's just harder to mess up.

I haven't had stability issues with HG (Workbench).

What are you going to setup as a server? If you have the time (approx. half a day), setting up rhodecode on a linux server is a good idea. It gives you user management and a web-interface beyond the shipped webserver of HG.

Ton

+1 to Rhodecode

[honoka]

I'm relying on HG. Have never really worked with Git since I'm happy with HG.

Since you don't have the time to dive into the SCC system you want to use I would advice you to go with HG, it's just harder to mess up.

I haven't had stability issues with HG (Workbench).

What are you going to setup as a server? If you have the time (approx. half a day), setting up rhodecode on a linux server is a good idea. It gives you user management and a web-interface beyond the shipped webserver of HG.

Ton

What about "TortoiseHg doesn’t support branching or merging. All of this will have to be done from the command line." and "The built-in server can only serve one repo at a time." on https://decibel.ni.c...curial-thoughts ?

Does TortoiseHg now support branching and merging on its GUI?

Does the built-in server really serve one repo at a time?

Edited August 27, 2012 by crocket

[Ton Plomp]

What about "TortoiseHg doesn’t support branching or merging. All of this will have to be done from the command line."

If you have setup merging (or three way diff) properly, you can call the merge tool from within TortoiseHG (note to self: 'write a blog post showing this)

and "The built-in server can only serve one repo at a time." on https://decibel.ni.c...curial-thoughts ?

That is correct for showing/sharing more that one repository at a time you'll need apache or the like. However I have chosen Rhodecode as the backend instead of HGweb since it features some management tasks (access control, forking, grouping and hooks).

See the documentation for more detail.

Ton

[0_o]

I'm currently working with TSVN yet I think all the available tools are not good enough for me. There are many missing features but the top for me are:

1. Project files are text files. How can you merge them without potentially breaking the project.

2. There is no Continuos Integration built into them.

3. There is no automatic builder that will create different versions of exes from the same project in the SCC.

4. Requirements + bug tracking integration.

5. Statistics over commits, bugs and benchmark dead lines.

I know this is not a tipical demand from a SCC but I end up always inventing the wheel while integrating different tools instead of having a central tool to handle all those close related subjects.

Though crocket didn't ask about it, how does perforce compair to SVN/GIT/Rhodecode now that it is free for small to medium groups?

[asbo]

1) Disable

1. Project files are text files. How can you merge them without potentially breaking the project.

2. There is no Continuos Integration built into them.

3. There is no automatic builder that will create different versions of exes from the same project in the SCC.

4. Requirements + bug tracking integration.

5. Statistics over commits, bugs and benchmark dead lines.

1) Disable merging/diffing for project files.

2-4) A versioning tool should not be playing these roles, something so monolithic would undoubtedly not work well. But you acknowledge that.

5) SVN at least gives you commit stats by user (and maybe some others) but TSVN provides some bug tracker integration. What dead lines are you expecting to track in a LabVIEW codebase?

[0_o]

5) SVN at least gives you commit stats by user (and maybe some others) but TSVN provides some bug tracker integration. What dead lines are you expecting to track in a LabVIEW codebase?

I would like to have the next mechanism:

1. IC over all the projects in TSVN.

2. Run tests and report once a day with an option to compare logs.

3. Use the logic of flight rooting to manage task from office project dynamically, taking into account the test and requirements logs.

The comparison to flight rooting is that a flight needs to reach a destination via some available roots with some stops on the way. Once reaching a stop on the way the root might change since there was an error or the optimized root changed or there was a new requirement. In order to reach the destination on the due date I need a tool that will know what state am I in and allow input from tests or user input along the way and thus creating a manageable task list with more predictable time tables while making it clear what caused each delay. A test could tell me if I reached the destination on time or not and even what resources/roots are available for me now.

Once I have a log of the entire root I can calculate the price vs. profit of the entire flight schedule and better predict future profitability of each flight/product.

However, this is off subject, I only wanted to know how Perforce is in comparison to TSVN and GIT while saying how frustrating it is to write everything myself with no end to end solution available.

I don't care so much if it is this SCC or that SCC. They all use the same merge and have their own issues. The thing I miss the most is an infrastructure that analyzes all this data and knows how to integrate with each tool.

As for excluding the text files, I already do it for some other files (xml/ini/aliases). Excluding lvproj or even manually merging them, as I do now, doesn't promise good integration.

Lately I'm having internal warnings each time I close LV and I wonder how much of it is related to something I did... maybe in one of the project merges.

Edited August 27, 2012 by 0_o

[Ton Plomp]

If you are looking into a project management tool there are options out there that cover these items. Hooking into these from within LabVIEW is most of the time an issue. I have no experience with that.

However most of the SCC's have management hooks that you can use to tell the project management tool what happened (see my post on integrating Rhodecode with Mantis).

Ton

[honoka]

If you are looking into a project management tool there are options out there that cover these items. Hooking into these from within LabVIEW is most of the time an issue. I have no experience with that.

However most of the SCC's have management hooks that you can use to tell the project management tool what happened (see my post on integrating Rhodecode with Mantis).

Ton

As far as I know, mantis is not a project management tool but a mere bug tracking system.

Edited August 28, 2012 by crocket

[Ton Plomp]

As far as I know, mantis is not a project management tool but a mere bug tracking system.

Correct, but you can use hooks to tell your project management tool what happened.

Ton