SVN on a local server......

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do all these svn thingies use a cloud to store the revisions?  nothing that can be setup on a local intra-net?  I have my own servers here and would prefer to keep my worthless stuff out of the public view for fear of shame.

 

JIm

 

EDIT:

 

Split from:

https://www.avrfreaks.net/forum/s...

 

JGM

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Thu. May 4, 2017 - 11:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You can run svn and git on your local machines. Not sure if they run under windows as you normally would use a 'nix os.
As an example, at the office we have our svn server which is just a PC running ubuntu. We also have Jenkins set up as our build server. Jenkins is set up so that when we check changes in, it builds our project and puts the hex/bin whatever files on an internal webpage. If something went wrong it emails you. Obviously the automated building is great for production code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Do all these svn thingies use a cloud to store the revisions?
No though there may be a svn service on a remote server farm.

jgmdesign wrote:
nothing that can be setup on a local intra-net?
There's a near plethora of version control systems.

Unix classics are rcs and sccs that can be on a developer's PC; IIRC, rcs is a part of a Unix training course and is relatively easy to learn and operate.

git is popular and can run on a local intranet server or on a remote server.

jgmdesign wrote:
I have my own servers here and would prefer to keep my worthless stuff out of the public view for fear of shame.
What one would think as worthless is of worth to either someone or an entity.

USA law on data leads to keeping one's data on one's servers; this is related to the USA federal constitution and "papers and effects".

Once data crosses a certain boundary it's a near free for all (literal and figurative)

Secure one's data on removable media and be ready to surrender to authorities all PC, phones, media, and debit/credit cards at USA borders and controls within STATE OFs.

Please be aware of USA and STATE OF asset forfeiture law.

If possible, consider traveling light (i.e. VPN or better, encrypted data-at-rest, crypto currency)

 


Debian

Debian

Package: subversion

https://packages.debian.org/jessie/subversion

Advanced version control system

Apache Subversion, also known as svn, is a centralised version control system. Version control systems allow many individuals (who may be distributed geographically) to collaborate on a set of files (source code, websites, etc). Subversion began with a CVS paradigm and supports all the major features of CVS, but has evolved to support many features that CVS users often wish they had.

This package includes the Subversion client (svn), repository administration tools (svnadmin, svnlook) and a network server (svnserve).

...

Debian

Debian

Package: cssc

https://packages.debian.org/jessie/cssc

Clone of the Unix SCCS revision-control system

SCCS is a per-file revision-control system. It is a de-facto standard on commercial Unices, being shipped with most of those.

GNU-based systems usually use RCS instead of SCCS - indeed it has been a choice to design RCS instead of implementing a free SCCS clone. RCS was designed to address some problems with SCCS (eg. extraction time grows linearly with the size of the history file), but it has anyway problems of its own (eg. extraction time of branches grows with trunk length).

Some project-wide revision-control systems, like Aegis, can make use of CSSC instead of RCS.

This package also provides a web frontend to navigate the history of files under SCCS control, with optional support for formatting of manpages using groff.

...

GitLab.com

Products

https://about.gitlab.com/products/

http://braumeister.org/formula/rcs  (rcs on Homebrew on macOS)

http://braumeister.org/formula/git (git on Homebrew on macOS)

Homebrew logo

Homebrew — The missing package manager for macOS

https://brew.sh/

https://github.com/obdev/CrossPack-AVR/blob/master/mkdist.sh

...

version_avarice=2.13

...

# The following packages are fetched from Atmel:

atmelToolchainVersion=3.5.4

...

via

CrossPack - A Development Environment for Atmel’s AVR Microcontrollers

https://www.obdev.at/products/crosspack/index.html

CrossPack is a development environment for Atmel’s AVR® microcontrollers running on Apple’s Mac OS X, similar to AVR Studio on Windows. It consists of the GNU compiler suite, a C library for the AVR, the AVRDUDE uploader and several other useful tools.

...

maxEmbedded

Setting up AVR-GCC Toolchain on Linux and Mac OS X

by

Jun 14, 2015

http://maxembedded.com/2015/06/setting-up-avr-gcc-toolchain-on-linux-and-mac-os-x/

https://okhouse.gov/images/header.jpg

Oklahoma State Legislature

4/27/2017

https://okhouse.gov/Media/News_Story.aspx?NewsID=5240

 

P.S.

NuGet is all I can recall that would be a package manager on Windows :

https://www.nuget.org/packages?q=Tags%3A%22vcs%22

https://www.nuget.org/packages?q=Tags%3A%22dvcs%22

 

Edits : NuGet, AVaRICE

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. May 4, 2017 - 03:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does a RaspberryPi make a sensible svn server maybe with an attached hard drive? Thinking my own (eg, ONE person) use only, a few software plus hardware projects per year.

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Apparently yes as Subversion is in Raspbian.

Western Digital has a hard drive, PiDrive, meant for a Raspberry Pi.

With a bit of effort and work, Debian can run on a Raspberry Pi.

 


http://www.raspberryconnect.com/raspbian-packages-list/item/96-raspbian-vcs

http://wdlabs.wd.com/

https://wiki.debian.org/RaspberryPi

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jims of both coasts!

 

If you have a old Windows machine just standing there then you can use that to host Subversion: https://www.visualsvn.com/server/

 

Also understand that you don't need a Subversion server in order to manipulate a Subversion repo from several machines. Just sharing the repo over your net as any other directory and using any SVN client of your liking should do (they all should support referencing the repo with a "file://" URL). There are some drawbacks of going this way, but as long as you don't commit from several machines simultaneously, and of-course back up your repo to a separate location regularly, it should be just fine for a one-man operation.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But why not use a cloud service?

 

I use one for $6.59/month which gives me unlimited repositories:

 

https://billing.sourcerepo.com/a... (see note)

 

The advantage, of course, is that it gives an offsite backup.

 

The content is secure - not public - but you can grant access; eg, to share code with clients/associates.

 

Note: The link is my "referrer" link: if anyone signs-up via that link, I should (apparently) get a small commission.

(I say "apparently" because it has never happened yet)

The direct link is http://www.sourcerepo.com/

Other services are available.

 

Even the free Github doesn't make stuff public if you don't want it to be.

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

There is absolutely no need for a server unless you want to access the same repositories from different machines.

I use SVN purely locally on my Windows PC, using TortoiseSVN for that.

If you want it on an intranet, that's just as easy as doing it locally as long as there is direct file access between the machines. Windows supports this natively, and IRC it's also very easy to set up using a mix of operating systems.

 

I really recommend it, it's free and simple: https://tortoisesvn.net/ 

 

-Patrick

"Some people die at 25 and aren't buried until 75." -Benjamin Franklin

 

What is life's greatest illusion?"  "Innocence, my brother." -Skyrim

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

pawi777 wrote:
There is absolutely no need for a server unless you want to access the same repositories from different machines. I use SVN purely locally on my Windows PC, using TortoiseSVN for that.
+1

 

But if the (AVR) code is "open" there is always free SVN hosting offered on spaces.atmel.com too.

 

If I am just "messing about" though I set one up on my HDD not so much for data security but so I can "wind back" if I need to. It also helps to keep a history of what you changed and why.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
But why not use a cloud service?

...

The content is secure - not public - but you can grant access; eg, to share code with clients/associates.

Context is European versus American :

I'm glad you have that right but I do not have that right.

For an explanation of why that is :

Julia Angwin interviewed on Moyers & Company

Julia Angwin discusses 'Dragnet Nation: A Quest for Privacy, Security, and Freedom in a World of Relentless Surveillance' on Moyers & Company.

https://player.vimeo.com/video/89055549

starting at 3m45s for a few minutes.

Third parties (entities) want access to information created by first parties (one) and second parties (other ones like partners, teammates, customers, clients, and operators)

It's a bit common to have first, second, or third hand experience with public and/or private corporate espionage.

What's regular in the news is nation state (governmental services corporations) espionage.

Relative to USA, data on a remote server can be made insecure via an order to the holder of that data (not oneself) whereas data on one's server is made insecure via an order to oneself; that's partially transparent other than if or when one receives an order in a National Security Letter (NSL)

With transparency, one can inform ones partners, teammates, customers, clients, and operators that the data is no longer secure.

 


Macmillan Childrens Publishing Group

Dragnet Nation

A Quest for Privacy, Security, and Freedom in a World of Relentless Surveillance

Julia Angwin

St. Martin's Griffin

http://us.macmillan.com/dragnetnation/juliaangwin/9781250060860

It's an easy read (it's not technical)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

BTW...

 

 

If you use Windows I highly recommend you get Tortoise to do your SVN stuff. As this shows things like creating a repository are VERY easy.

 

(though they do warn here about using a local repo - that's simply because of the concerns of data security - if your HDD crashes you will lose both your working copy and the repo that might be able to restore it)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
But why not use a cloud service? I use one for $6.59/month which gives me unlimited repositories:

 

Because Jim (the East Coast one) is tired of every time I turn around handing over $XX.95 a month for something, that's why!

 

It all adds up for me at least, and I am pruning (fancy term for cancelling/getting rid of) a lot of 'services' around here both personal and professional. $70.00/year for a SVN service that I can host here for my four machines that would use it is not economical for me at least.  Sure I could write it off as a business expense but I am borderline out of business so why spend the $$.

 

As I said, I am cancelling a lot of small $$ monthlies that when added up are an expense I could do without.

 

jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Cliff - never knew that tortoise could do a local repo! At least you won't have others checking in underneath you!

For those of you that have not had the benefits of version control, here's some little pointers:

1. before you check in, use the diff feature to compare your changes just to make sure you haven't done anything too silly

2. put useful comments when you check in - you'll thank yourself later

3. learn to use diff

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
3. learn to use diff

 

Whats the diff anyway?cheeky

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

pawi777 wrote:
There is absolutely no need for a server unless you want to access the same repositories from different machines.

In fact there is no absolute need for a server even if you want to access from different machines on a local network - as described by me above.

 

There are advantages with a server, though. To think that the built in repository handling in a client (like TortoiseSVN) is the same as in a server is wrong.

 

One thing a server has is "transaction handling" - i.e. a commit either gets completely done or not done at all. This comes into play when you loose power or your server kernel crashes violently in the middle of a commit. Clients don't have this functionality. Hence the urging to be meticulous with backups - especially so when running server-less setups.

 

  1. Take your old Windoze machine that is collecting dust.
  2. Install TortoiseSVN on it.
  3. Create a repo, using TortoiseSVN as described above, on that old machine.
  4. Make it share the directory with the repo over the network.
  5. On your actual developer machine(s) set up drive letter for that "share", say "N:" pointing to that folder.
  6. Install TortoiseSVN on it.
  7. Now just check out "file:///N:/trunk" on your developer machine and you have a working copy of the trunk of the repo on that other machine.
  8. Do 5 to 7 for any other machine you want to be able to do SVN ops from.

 

I realise West Coast Jim runs Macs as some of his "clients". I have no clue as to what SVN clients are available (though I presume the command line client is). If your Mac at all can reach a Windows share then a Subversion client should be able to work with a repo on that share.

 

If you want to go for a server, then (as I recall  - it's been a few years since...) installing and setting up VisualSVN isn't much complicated at all.

 

PS.: Notice the three slashes to cope with Windows drive letter notation when you reference a repo.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. May 4, 2017 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
never knew that tortoise could do a local repo!

That is a most useful feature. And it's not only for TortoiseSVN. Any client should be able to do this.

 

This means you can take your own Subversion course playing around before starting off for real. I really, really, really recommend this. Just set up a toy project, blinky or whatever, and play around.

 

There are things to think about before starting, mainly repo organisation. The "standard" structure you read about is something like this:

 

<root>
  |
  +-- trunk
  |
  +-- branches
  |
  +-- tags

My first recommendation is to stick to this unless you know better.  Even if you don't start out branching and tagging you will be eventually be happy that the trunk "level" is there so that you can have a sane structure if you eventually branch/tag. Also,l since this is widespread convention it will likely make getting help simpler.

 

The second complication is when you have several (more or less) separate products/projects. Do you place them all in one repo, or in separate ones? If in the same repo, then what structure should you choose. Two reasonable variants are possible:

 

<root>
  |
  +-- product1
  |     |
  |     +--trunk
  |     |
  |     +--branches
  |     |
  |     +--tags
  |
  +-- product2
  |     |
  |     +--trunk
  |     |
  |     +--branches
  |     |
  |     +--tags
  .
  .

and

<root>
  |
  +-- trunk
  |     |
  |     +-- product1
  |     |
  |     +-- product2
  |     .
  |     .
  |
  +-- branches
  |
  +-- tags

There is no general "best" here - it depends as we so often say. With absolutely no guarantees for "best" I'd recommend the former structure, unless more info is given. I take that back - it really depends. A few seconds after posting I leaned towards the second alternative. Then back. Then forth... Ask/discuss if you want to know what's making me oscillate in this way.

 

There is also the complications of

- "External things", like source code "libraries" [I feel Cliff cringing now...]

- Code shared between products (i.e. "own source code libraries")

 

Subversion has no problem handling such, but if you store them without redundancy then you might get into structural trouble if you don't want to treat them as separate projects in your build environment (e.g. in AVR Studio). OTOH, storing them redundantly within each project that uses them will of-course get you into massive maintenance and version problems - which is one thing you're trying to get away from with a versioning system in the first place. There are several possible workarounds:

- Keep the "shared assets" as separate projects and build them into binary libraries that you then link to your product projects when building the latter.

- Use Subversion "externals". I will not dive into that here and now, but for the curious of mind, see this: http://svnbook.red-bean.com/en/1...

 

Do note that such "structural conflicts" are not so much a Subversion artifact as a they are a general problem when sharing code resources between several projects. Don't shoot the piano player..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Thu. May 4, 2017 - 01:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, silly question time for me.....

 

Currently, I have a folder for every job I get.  Inside this folder are subfolders for invoices, expenses, engineering, software etc.  In the Engineering folder is where all the code is stored along with schematic and PCB files.

 

This is all very handy as everything related to that project is in one folder, or one of the projects sub folders.

 

By using an SVN system, does this mean I can no longer keep things as I have them, and now must move all code to the SVN's folders?

 

JIm 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not at all. You choose what it is that you want to "push" into your repo to have version management. As a very simple example when you create C programs you have things like .o and perhaps even .hex that are "generated" files so, because they can be regenerated at any time you might choose to only keep the .c files in version management.

 

Having said that this might actually require version managing the compiler you use because to recreate a specific .hex you maybe need not only the .c but the exact version of the compiler that takes that and generates the .hex so you may actually choose to keep .hex images in version management too. However there's almost never any reason to keep intermediate binaries like .o files.

 

As it happens, if you get the hang of this and especially if you were to start using a "cloud server" to keep a maintained copy of the repository you might even choose to push things like invoices into version management anyway. That way, after 5 years and 2 hard drive crashes you can still go back and pull out that 3rd invoice you sent and now realise he never paid!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To add to what Cliff says: You can "map" any working folder to any folder in the repository. So if you have your project like this on your hard drive:

C:
 |
 +-- Projects
       |
       +-- EmpireStateCabling
       .     |
       .     +-- Invoices
       .     .
             .
             .
             +-- Code

And your repo is structured

<root>
  |
  +-- EmpireStateCabling
  |     |
  |     +--trunk
  |     |
  |     +--branches
  |     |
  |     +--tags
  |
  +-- OtherProject
  |     |
  |     +--trunk
  |     |
  |     +--branches
  |     |
  |     +--tags
  .
  .

Then you would have C:\Projects\EmpireStateCabling\Code "mapped" to /EmpireStateCabling/trunk in your repo (assuming you actually want to "be on" the trunk, i.e. not on some branch). This is accomplished by simply doing a checkout in Subversion, of that part of the repo, to that position on your hard disk.

 

This brings up a very important point: You do not need to have a local working copy of the entire repository. You only check out "as much as you need" (in 99% of all cases this means checking out a "root of a product", and to begin with you can read that as e.g. /EmpireStateCabling/trunk . (If you eventually want to do branching, then it might be something like /EmpireStateCabling/branches/phase2maintenance ...)

 

Also a +1 for the possibility to version control "everything" including stuff like invocies, specifications etc. Since you already have a well thought out structure for a complete project tree, then you could just as well store it all in Subversion. Although there would be no revisions of invoices (that would likely be "creative book-keeping" ;-) ) it makes some sense to have everything in one place. Then you'd backup the repo and everything essential is secured. The drawback is that you need to make damn sure your repo is secured, and in no way corrupted or youre left with a broken safe with no key. Also, after a crash, the restore involves not only opening a backup to get to e.g. an invoce, but also to install Subversion, roll back the repo, check out a working copy and then pick the invoice up from there. No free lunch and all that..

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I was not looking to store the entire project folder, just the source code.  All of this is currently on one of my servers, and the data is backed up to a local NAS, and to a remote NAS in a different location.  I was thinking if it is possible to simply do the code folder.

 

Might have to first do a local setup, THEN move on to the centralised configuration....

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
I was thinking if it is possible to simply do the code folder.

It is.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very enlightening discussion. Having to read, reread, and reread again, but, I hope it will eventually "take".

 

Jim - the West Coast one

 

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use VisualSVN Manager for my server on my desktop machine so that I can leave it running and also access my repos on my laptop. I then just use TortoiseSVN for the client to pull/push sources.

 

Kartman wrote:

Cliff - never knew that tortoise could do a local repo! At least you won't have others checking in underneath you!

For those of you that have not had the benefits of version control, here's some little pointers:

1. before you check in, use the diff feature to compare your changes just to make sure you haven't done anything too silly

2. put useful comments when you check in - you'll thank yourself later

3. learn to use diff

 

Agreed. I diff every file when I make a commit to ensure I know EXACTLY what I am sending to the repo.

My digital portfolio: www.jamisonjerving.com

My game company: www.polygonbyte.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How in the world do you use diff on a new project when you are adding header and code files right and left, then decide that you don't to use this one but that one, instead? How can you even define "too silly" in this context?

 

Perplexed!

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:
How in the world do you use diff on a new project when you are adding header and code files right and left

Well, new files being added obviously can't be diffed, so that's an exception.

 

ka7ehk wrote:
then decide that you don't to use this one but that one, instead? How can you even define "too silly" in this context?

With a proper design, most of these problems can be caught before you even have that problem. However, of course not all problems can be found in the design phase.

 

If I have two files, they both get committed to the repo. If I then need to delete a file, it gets deleted. Because of the nature of version control, I can always revive that file (at any stage of its life in the project).

My digital portfolio: www.jamisonjerving.com

My game company: www.polygonbyte.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@Jim:

In Subversion you can "diff" your current local work against the latest revision in the repository.

You can also "diff" it against any other revision in the repository.

You can also diff two revisions in the repository against each other.

 

In all the above cases Subversion will promptly tell you

- Which files exist in both places but are different. You can then drill into that and see the difference, line per line, between the two instances of that file.

- Which files exists in just one of those places - i.e. files that have been deleted or added.

 


 

Next, let me put up this declaration (warning?) before we get any further:

 

Any version control system will have it's quirks. I will refrain here from talking about other version control systems, but will say this re Subversion (so that you don't hit me later with "why didn't you say so from the start!"):

 

  • For many operations, but not all, you will need to be in contact with the repository (e.g. the SVN Server if you run such). Not having this contact will not stop you from editing files locally, but it will e.g. stop you from doing a commit.

 

  • There are some "quirks" for more advanced stuff, mainly to do with "merging" - the operation to bring work done on a "branch" back to e.g. the "trunk". The quirks does not necessarily happen all the time, and there are ways to deal with them. This forms a PITA first and foremost when working on a big project file tree (tens or hundreds of files and directories) and when moving and renaming files around (re-organizing your project file tree). Less likely for an 8-bit AVR project which often amounts to at te most a few tenths of files and very few directories. (If you're curious then Google "Subversion tree conflict" and similar). Anyway... Branching, and possibly merging, are not the first things to learn re Subversion.

 


 

Your first endeavours into Subversion will be a learning experience. It is best not to use a "real" project for this first learnings. Use a toy project that you can afford to mess up. It can be a copy of a real project if you like, but don't invest any "real" work into it. Chances are you will have a mess after a few days. There's this maxim to development, and it holds when learning Subversion also: "Prepare to throw one away".

 


 

There are a lot of Subversion clients out there. And there is a plugin for AVR Studio also (AnkhSVN). In my opinion it will only confuse things if several and/or different clients are used. Also, some clients might be good for the experienced user but will not necessarily be good vehicles for learning.

 

I prefer TortoiseSVN. It's "exposing the philosophy" of Subversion in an excellent way. It has a nice user interface. It runs on any Windows version that isn't from the last century as far as I know. It is all you need to begin. What you learn in TortoiseSVN will serve you well whatever client you eventually decide upon. The command line client is the "canonical" one, but pushing that aside the next one is TortoiseSVN.

 

I am sorry I have no recommendation regarding Subversion clients for MacOS.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to wikipedia, there are Mac OS clients.

https://en.wikipedia.org/wiki/Co...

"SCSI is NOT magic. There are *fundamental technical
reasons* why it is necessary to sacrifice a young
goat to your SCSI chain now and then." -- John Woods

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skeeve wrote:
According to wikipedia, there are Mac OS clients.

If that was in answer to my post: I have not claimed that there aren't any.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pretty well anything that is on Linux is on the Mac. I normally use phpStorm and it's plugin for SVN or command line. I've not seen anything quite as good as tortoise on 'nix.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
I've not seen anything quite as good as tortoise on 'nix.
Have a look at RabbitVCS - not quite as good as Tortoise but it integrates SVN operation into Nautilus or whatever file explorer you use on Linux.

 

EDIT: on this page it says that it includes integration into the "Finder" file manager in Mac OSX.

Last Edited: Fri. May 5, 2017 - 11:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... that's partially transparent other than if or when one receives an order ...

or command from one in U.S. Customs and Border Protection (USA CBP)

It's common for source code to be copied from a server onto one's notebook PC, tablet, and/or smart phone.

One's (USA citizens and residents) seized devices, and it's TBD that data on seized devices, can be recovered by a USA Rule 41(g) motion filed in the appropriate USA federal district court; the court's magistrate or judge will quickly rule on the motion and, if successful for one, one's seized devices are returned.

The probability-of-failure is apparently 0.007% so the risk is likely very low unless the therefore seized data is of high consequence-of-failure (cost to one and one's customers, operators, partners, and teammates)

 

Ars Technica

Woman: My iPhone was seized at border, then imaged—feds must now delete data

Lawyer: "They provided no justification for why they took the phone."

by Cyrus Farivar

8/23/2018

https://arstechnica.com/tech-policy/2018/08/woman-my-iphone-was-seized-at-border-then-imaged-feds-now-must-delete-data/

...

Instead, in federal court in New Jersey on Wednesday, her attorneys [in Lazoja v. Nielsen et al] filed what’s called a Rule 41(g) Motion, otherwise known as a "Motion to Return Property."

...

 

From 0.005 percent to 0.007 percent

...

That case [Alasaad v. Duke] grapples with whether Americans can be compelled to unlock their digital devices upon returning home.

...

In order to search and seize someone’s device without a warrant—something that would otherwise require one—federal authorities rely on what’s known as the "border doctrine." This is the controversial but standing legal idea that warrants are not required to conduct a search at the border. The theory has been generally recognized by courts, even in recent years.

 

Greasing the wheels of justice

...

[USA CBP exceeded the 90 day limit resulting in the creation and filing of a USA Rule 41(g) motion and an affidavit with the motion]

[during the 90 days the phone's data was copied]

[the case's attorneys are requesting multiple orders from the judge wrt data and basis]

In addition, the attorneys want the court to essentially overturn the border doctrine and prevent them from doing something similar in the future, which may prove to be a tall order.

One advantage of a Rule 41(g) Motion is that it can be seen by a judge relatively quickly; Lazoja’s attorneys have asked for a hearing on September 17.

 


In "Dragnet Nation", Julia describes USA border doctrine and how one deals with that (purge all data on the devices, enter the border, surrender the devices if commanded to)

Julia may also recommend, if commanded to, surrendering the devices' passwords and/or unlocking the devices.

iow, zero data at the USA border.

 

"Dare to be naïve." - Buckminster Fuller