Page 1 of 1

SVN - committing data files or not

Posted: Mon Oct 05, 2015 1:01 am
by Susan Smith
This is for Gabriel or Laura, primarily...

I was hoping to follow-up on your SVN presentation at the conference with a question. When we had the sample programs and data on our flash drives and we were committing them to the blank repository, did we actually commit the data files the first time so that they were in the repository and then set them to ignore afterward so they wouldn't be updated? Or did we not commit them at all? I was thinking that if I wanted to host my repository on a cloud-based host, I don't have permission to put my client's data up there - whether it will be updated later or not. Can I just *ignore* those data files from the very beginning so that they are NEVER up there at all? (Maybe we did it that way, but I got a bit overwhelmed with all of the material and lost my footing a bit by the time I got home.)

I can see that moving to an SVN (I haven't actually done it yet on my desktop), forces you to clean up your act. I have a lot of temporary files that I create in various folders, and I constantly make temporarily copies of things - programs, data, small routines, etc - that I am trying out before I decide which works best. And I also have code snippets (like the FNOPEN sub-routine that you have to use as a wrapper for FNOPENFILE in FileIO. I tend to just keep them sitting in my BR folder, so I can merge them into each program that opens files with that routine. So since the commit routine in SVN will show all of those new files and force you to account for them - either by adding them to your depository or ignoring them, I realize that it really helps to clean up your folders first and perhaps change my sloppier programs so that ALL temp files are created in the same folder for simplicity. Secondly, in Mikhail's talk about MyEdit, I see that I can avoid the issue of the FNOPEN routine by using MyEdit's code completion options to paste that FNOPEN routine into my programs if I use the editor to write my code. Lots of food for thought.

But my primarily question is whether or not I have to commit data files to the SVN that I know I will never wanted updated.

Thanks.

-- Susan

Re: SVN - committing data files or not

Posted: Mon Oct 05, 2015 9:03 am
by laurajs5
Good question. We did not add the data files to the SVN at all. They are only located on your own computer, client side, for testing etc. When you send the new or revised programs to your clients, they would be accessing their own data files stored on their own server/disks when run. This provides security and also prevents accidental upload of bad test data.

Re: SVN - committing data files or not

Posted: Mon Oct 05, 2015 9:13 am
by Gabriel
First of all, you never put your data in the SVN.

For starters, its kind of a pain to ignore something after it was added.

But mostly, you never put anything on the SVN that you don't send to your client. Test data definitely does not get sent to the client (or you'd overwrite their real data with test data which would be a disaster!).


Also, SVN is secure. It uses https for all transfers making it highly secure and the repositories are encrypted and the only way to access them is with the user name and password you created when you set up the SVN.


But, secure or not, why pay for a cloud based SVN??? SVN is free and you can host it yourself really easily - you already installed it on your laptop and it took less then 10 minutes .. just install it on whatever computer you want.

Additionally, I offered my own internet based SVN service a couple years ago and you were profoundly uninterested. Nobody was. You told me the reason was because you wanted control over the SVN yourself -- so just install SVN yourself and keep that control!!



Now, regarding your other question - I think its actually kind of the opposite: Using SVN does not force you to get organized! It HELPS you get organized.

There's no need to organize things BEFORE you use the SVN. Instead, Start using the SVN first, and THEN organize things, using the SVN to help with the organization process.

Once something has been marked "ignore" by the SVN there is no longer any need to worry about deleting it or anything else -- its just an "ignored" file, not part of your software any longer. And the SVN itself is the easiest way to mark things as important or not important.

When you try to organize things before you start using the SVN you have to do so with Windows Explorer, where, if you're not careful, you can accidentally delete important things or move things around.. SVN protects all that, and guides you through the process of the cleanup. That was one of the main points of the presentation!!

Prior to the conference, you asked about how to organize your data .. and SVN is a good way. Additionally, SVN provides a backup in case you accidentally delete something or accidentally move things around, and it keeps track of all changes you make so you can easily find out what happened later, in case something did move somewhere or get deleted accidentally.


The whole point of SVN is to make things easier, not harder :) Its not there to tell you to "clean your room" .. SVN is there to HELP you clean your room, (so to speak.)

gabriel

Re: SVN - committing data files or not

Posted: Mon Oct 05, 2015 10:17 am
by Susan Smith
When I said that SVN forced me to clean up my messes, that was a good thing! The specific situation that I had in mind was that I create temporary files all over the place and make copies of things as I am testing. If I was better at keeping those things in one or two places, I could simply ignore the entire temp folder(s) and not be confronted with new lists of files to ignore whenever I commit changes. Cleaning up is a GOOD thing.

As for the location of a repository, I don't have a computer to use as a server right now, which is why I am considering other options. And I already have cloud space on Dropbox, Rackspace, Cubby, Google Drive and OneDrive. So it makes sense to consider using that if it's possible. BUT I may set up a server anyway that can be used for this as well as development in Client Server, which I hope to be doing sometime in the near future if they decide to go that way. We'll see. I have a better understanding of the initial SVN commit phase now.

-- Susan

Re: SVN - committing data files or not

Posted: Mon Oct 05, 2015 1:57 pm
by Gabriel
I know its a good thing!! I didn't mean to imply otherwise.

I'm just trying to explain, to help you get the most mileage out of your SVN.


Its much easier to right click on the files and click "Ignore" in whatever random locations they're in, then it is to change your software to put all temp files in a temp folder!!! The whole point of using SVN is so you don't have to change your programs unnecessarily! SO I'm trying to help you get the most out of it.

Simply check your programs in, and when you do that, it becomes very easy at that time to mark which files need to be ignored and which ones don't. Then you're done!! No reorganization necessary - it never matters again because the SVN takes care of it for you.

I think maybe the reason its confusing is because for the conference example I had everyone start out with a really organized project. That was because (a) we were starting fresh anyway, so why not make it clean and (b) in the conference I had so much information to cover and so little time, that we ended up with just 10 minutes to do the entire First Time Commit process!!! If I'd had even 20 minutes it would have been enough time to give a proper example but as rushed as we were we had to do everything we could to make it all go as fast as humanly possible.


Explained another way: It took 10 minutes to check in with a clean folder structure. It would have taken 20 minutes to check in with a messy folder structure. But it took an hour to clean up the folder structure (we did it before the conference so everyone could see a fast and clean example.) Thats for a simple example.

For a real software example, it takes 15 minutes to do a First Time Commit for a clean folder structure, and maybe 40 minutes to do it for a messy folder. But it takes 2 hours to clean the folder, and if you have to change your code, you're looking at an 8 hour investment.

Who would spend 8 hours just to save 25 minutes?


The whole purpose of SVN is to make this stuff easy. I just want to make sure I explain this carefully so you get the best use out of it.


I do this all the time with completely different BR software for various BR customers. I have never once changed their programs or reorganized ANYTHING before putting stuff in the SVN. I would never do that - it would be sabotaging myself.

Just put it in the SVN, and mark things "ignore" or "include" once and be done with it.

Gabriel

Re: SVN - committing data files or not

Posted: Mon Oct 05, 2015 2:01 pm
by Gabriel
Susan Smith wrote:As for the location of a repository, I don't have a computer to use as a server right now, which is why I am considering other options. And I already have cloud space on Dropbox, Rackspace, Cubby, Google Drive and OneDrive. So it makes sense to consider using that if it's possible. BUT I may set up a server anyway that can be used for this as well as development in Client Server, which I hope to be doing sometime in the near future if they decide to go that way. We'll see. I have a better understanding of the initial SVN commit phase now.

Wonderful! And I don't want to discourage you from getting a cloud repository (or even using the one I make available for BR programmers).

But if I were in your position, I would just use your laptop (or your desktop) as the SVN server. Its always running any time you're programming, so it will always be available for you! No problems!


And definitely don't buy some "server computer" from dell for $4000 - all that does is give you more complicated settings that you don't need. And that makes it a headache to configure.

Gabriel

Re: SVN - committing data files or not

Posted: Mon Oct 05, 2015 2:03 pm
by Gabriel
Sometimes, its almost hard to believe how simple this stuff can be! There's definitely a natural tendency for us programmers to try to make things more complicated then they need to be. But with programming, the simplest solution is always the best solution. And in BR we've gotten things to the point where they can be pretty simple indeed! That's one of the biggest benefits of working in this language!