|
As I said, I am a single programmer (1 man shop). I do not work in a corporate or team environment.  . I still use it for my VB6 legacy support work.
So far I have replaced it with a 9TB Raid 5 array and different backups for each day of the week Monday through Saturday. (Never work on Sunday). I tried Tortoise SVN but was extremely unhappy with the lack of documentation, and how cumbersome it is. I also tried TFS, with similar complaints.
If you know of anything for revision control NOT for someone working in a Team environment, I would love to hear about it.
It is hell getting old but still beats the alternative.
|
|
|
|
|
I would have recommended SVN, but you already tried it. Did you ever try the SVN command line without Tortoise? Just recursively commit your whole directory tree whenever you want to make a recovery point.
If you ever need to recover, pull the commit number you want into a new directory tree.
Mercurial or git with a local repository would probably have similar behaviors.
|
|
|
|
|
I gave up using command line when CPM died. But thanks for the suggestion. Please check my reply to BR.Bill, below.
One of the problems of working alone is there is no one that has used any of the new software revision systems to explain the how to and ins and outs.
"One is the loneliest number...." 3 Dog Night.
|
|
|
|
|
Ed Aymami wrote: So far I have replaced it with a 9TB Raid 5 array
Just noting that source control and back ups are two different things.
One should do both.
|
|
|
|
|
I know that. But we all do the best we can, with what we've got.
I have found that rarely do I need to go back more that a day or two to fix a horrendous blunder, the way that I work. (Slowly and methodically). It is one of the advantages of working alone. 
Age, experience, and hard work usually overcome youth and talent...
|
|
|
|
|
Ed Aymami wrote: I don't know why MS dropped it.
Oh, man, there's not enough time to unspool the full answer.
SourceSafe is a corruption machine. If there's one thing SourceSafe does really, really well, it's corrupt your source base.
But there are a ton of other reasons!
|
|
|
|
|
I am not sure what experience you have had, but I have been using it since it first came out. I have never had it corrupt any files for me. I guess that is because I don't work in a team environment and the things I store are pretty vanilla.
I guess I am just getting old and cranky but I wish MS would take UX into account when there is only one person using it. A good revision system for me would work like Source Safe does, (but without corrupting the files as you have experienced  ).
One should not need to purchase a $50.00, 560 page book to learn how to use TFS or any other Revision software.
KSS is the best rule to follow.
|
|
|
|
|
I've had many years of experience with VSS, both as developer and administrator, especially during the thick of its popularity.
It makes sense that it's less problematic for a person working alone. In a multiuser environment, it's absolutely awful.
It's funny you bring up TFS. It's lousy too, but for different reasons. It's maddening to work with and lots of people use it because it's bundled (which is how VSS got popular). That they're giving away a commercial product should tell us something about how committed Microsoft is to making it good. Come for the integration with Visual Studio, stay for the ... wait, why am I staying?
If you really like VSS's model and paradigm, there are a fair number of products, free and commercial, that are easy-to use, yet much more robust (and still kept fresh). I don't think you'll be sorry if you dig around and find one.
Hell, you can even use Perforce for free if you're all by yourself and your source base has fewer than 2000 files. You can use it either as simply or as complex as you like, and the GUI, though not flashy, is solid. It's really fast, too. Some folks don't like it, but it uses a similar checkin/checkout model as VSS. And it's probably the most reliable source control product made; even people who dislike its model don't deny its reliability.
There's a saying about VSS: It's not whether VSS will corrupt itself or not. It's when.
|
|
|
|
|
Thank you for the tip. I can not agree with you more about TFS.
I will try to find Perforce and take a look at it. Is the learning curve steep?
I appreciate your response.
We think we're cruising down the highway when (something, something, something) slip sliding away.
|
|
|
|
|
The name for the product is "Perforce HelixCore". It just used to be "Perforce", but you have to make it sound fancy these days. Here's a link to the free setup.
It consists of a server ("P4D") and some clients -- the P4V GUI and the P4 command line. The server can just run on the same system you develop with. No big deal. It's super low in resource usage.
The learning curve lies in setting up the server (not hard) and figuring out how to design a workspace layout. If you're just using the GUI ("P4V") and you have a typical source tree layout (if you're using VSS, then you almost surely have such a layout), it shouldn't take you very long to get used to it.
The command line is very powerful.
There are Visual Studio plugins that you can download from Perforce.
|
|
|
|
|
|
Br.Bill wrote: SourceSafe is a corruption machine
Hmmm...rather certain that is a historical problem.
Long ago, like in the times that link was referring to, it was fairly common for businesses to find that their databases had been corrupted. That was true of MS Access, Oracle and SQL Server. Never heard of DB2 doing it but I suspect it did and it was just that I didn't follow DB2.
There were even strategies that one was suppose to follow to lessen the chances of that happening.
But I haven't heard of that happening for a long time. Probably because hardware has gotten a lot better and because backups and redundant layouts have gotten much better.
|
|
|
|
|
Probably because the number of VSS shops has dropped considerably.
|
|
|
|
|
Dean Roddey wrote: ++ - Why has the committee spent all this time creating a cathedral to container abstraction, while seemingly ignoring the fact that you can't write even a modest C++ program and remain within the standard? I.e. you have to throw in a bunch of third party bits and bobs, because there's been not much progress towards a reasonably full featured cross platform (even if some of it is only applicable on the mainstream) system. I think that the latter would do far more to allow C++ to compete against things like C# than the ability to remove every third odd numbered duplicate vector element.
[...]
At some point C++, if it's going to survive, is going to have to just cut off some of the past and move forward, IMO.
It seems to me that it is for reasons like this that C++ has probably had its day. C++ isn't going to go away totally of course but I think it will become less and less important over time.
What will replace C++ as a low level, high performance, cross platform language? Rust, Go, and maybe even D (D being in a relative niche).
|
|
|
|
|
I'm working towards open sourcing the general purpose half of my system. It's about a millions lines and the bottom half is a full, general purpose development environment, which doesn't use the STL or standard libraries at all. It's a whole world unto itself. Of course many people will use the standard no matter how unfortunate its circumstances, but I will be providing a powerful alternative. I'd hope to maybe build a community of disaffected C++'ers around it maybe.
I looked at Rust and it's so restrictive. You immediately start thinking of how hard many things you'd done in C++ would be to do in Rust.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: I looked at Rust and it's so restrictive. You immediately start thinking of how hard many things you'd done in C++ would be to do in Rust.
Yes, indeed. But I think that Rust fans would say that that is a strength. Rust prevents you doing some of the (bad) things that you might have done in C++. I.e. It immediately eliminates whole classes of bugs (they say).
This article, Implications of Rewriting a Browser Component in Rust[^], which I saw earlier today attempts to illustrate this strength of Rust.
I came to Rust not from C++ but from (mostly) C# and it's even more of a culture-shock for me. As you say, the immediate reaction is "this is going to be much harder than I am used to". I realised that I would need to think about what I was doing very, very carefully to begin with -- at least until I really began to grok Rust's ways of memory management. Semantically Rust is very different to C#, even more different than C++ is to C#.
So I would not claim to be a Rust fan just yet but I think there is something in Rust fans' claims of better memory safety, especially in concurrent/asynchronous environments. Yes, it's harder (at least to begin with) but it should be worth it.
Or just use Go instead. 
|
|
|
|
|
Of course the ultimate issue is that it's hard to picture another language becoming dominant at this point. Life it short and putting in the time to become really proficient in a new language that may not ever provide any career benefits is a hard call to make.
Of course the same could be said about continuing to dig into C++ as well I guess. The number of C++ jobs out there are dwindling, and if you are a Windows guy even more so.
Explorans limites defectum
|
|
|
|
|
markrlondon wrote: What will replace C++ as a low level, high performance, cross platform language? Rust, Go, and maybe even D (D being in a relative niche).
No evidence of that.
TIOBE Index | TIOBE - The Software Quality Company[^]
Matter of fact from the historical perspective right now there is no replacement of anything going on. Pundits that are fiscally bound by some new language like to claim that their language is going to dominate but wouldn't want to put my money on one of those bets.
|
|
|
|
|
Time will tell. 
|
|
|
|
|
Dean Roddey wrote: GIT - After all these years, I can't be the first person who wants to manage multiple separate...
GIT is a poor tool for managing any enterprise business code base.
But to be fair it was specifically designed for the open source online projects.
With GIT in the enterprise you have the following choices.
1. Use one repo
2. Rigorously handle projects as independent deliverables.
3. Fumble around with adhoc attempts to manage multiple repos.
4. Find a different source control tool.
Dean Roddey wrote: And, though having the intellisense stuff is very helpful, it can be incredibly intrusive and annoying sometimes.
Yep. In my case something keeps popping helpful hints right on top of the code that I am typing.
I would turn it off but sometimes I do rely on it.
Dean Roddey wrote: And, it seems to want to force you to have all customizations be per-user.
In intellisense? I know you can customize VS and provide probably basically any functionality you want, so you could do that for a group. I believe that there is a way to customize intellisense for groups which is a bit easier than a full custom plugin. Not something I want to see given that people think they are "improving" code quality by adding trivial syntax checkers already. No reason to encourage them to do it adhoc.
Dean Roddey wrote: C++ - Why has the committee spent all this time creating a cathedral to container abstraction, while seemingly ignoring the fact that you can't write even a modest C++ program and remain within the standard? I.e. you have to throw in a bunch of third party bits and bobs, because there's been not much progress towards a reasonably full featured cross platform (even if some of it is only applicable on the mainstream) system.
Huh? Every language uses 3rd party frameworks. I wouldn't work for a company that required I use only the language to build everything unless they wanted to pay me a lot of money and guarantee years of work before anything would go out the door. Even then I would probably just copy the open source stuff.
And that isn't new. There were 3rd party repositories for C and Fortran long ago. (Presumably still are but I don't work with those now.)
Dean Roddey wrote: Similar to above, while ignoring fundamental things like enumerations, which suck in C++
Enumerations suck everywhere. The problem is that people want them to be more than just a integer numeric constant. That isn't the fault of the implementations however.
Dean Roddey wrote: At some point C++, if it's going to survive, is going to have to just cut off some of the past and move forward
At some point if Cobol/Fortran/C is going to survive it is going to have to move forward.
Except they are.
And I am positive that I will be dead before the last Cobol/Fortran/C program is retired.
And it will be generations, if ever, before C++ is laid to rest.
|
|
|
|
|
Well, there's dead and there's dead. The job market for C++ is already really bad compared to other stuff. That's ultimately what matters, not how long code based on it sticks around.
On the third party thing, it's that they've just not addressed the issue of portable libraries that are part of most all practical applications. C# has a huge advantage here. If you hire a C# developer, he's going to have used a scheme for doing all those common things because it's a standard part of the language package. In C++ that's not the case.
BTW, I'm doing my part to try to alleviate this problem, though the specifics of it will probably mean it won't be attractive to most folks.
I've open sourced the general purpose half of my very extensive C++ code base[^]
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: The job market for C++ is already really bad compared to other stuff.
Evidence? Have you attempted to get a job in the embedded device space?
Following is what I use for a source.
TIOBE Index | TIOBE - The Software Quality Company[^]
Dean Roddey wrote: On the third party thing, it's that they've just not addressed the issue of portable libraries that are part of most all practical applications
Who is "they"? C++? Yes they have. And they have done so for decades.
Dean Roddey wrote: C# has a huge advantage here
Over C++? Perhaps. But in my experience Java has much more depth in competing solutions in the enterprise space.
Dean Roddey wrote: n C++ that's not the case.
Been a long time since I did enterprise development in C++, but I will note that LNP (Local Number Portability) management was written in C++ and it definitely involved a wide array of technologies. And that was 20 years ago.
|
|
|
|
|
Most of us don't have experience in embedded work. That's a fairly specialized thing.
Explorans limites defectum
|
|
|
|
|
Doesn't mean that there is not a 'lot' of work however. Also, very definitely, doesn't mean it is going away either, so that work will continue.
|
|
|
|
|
Well, 'lot' is a relative term. C++'s piece of the pie seems to pretty clearly be on the downhill slide. I don't at all celebrate that since I have a HUGE vested interest in the language, aka my entire life. But the universe has made it clear by now that my interests aren't terribly important.
Explorans limites defectum
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
