Source code revision control

Log in or register to post comments
Go To Last Post
73 posts / 0 new
Author
Message
BetterSense
BetterSense's picture
Level: Wannabe
Joined: Mon. Jan 24, 2011
Posts: 84 View posts
Location: Dallas
#1
Posted by BetterSense: Mon. Mar 5, 2012 - 04:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the correct practice for keeping track of software projects, which makes sense for microcontroller programs?

I am just a hobby programmer and I currently just keep my programs in folders and edit them as needed. When I get to a point where I think the code is stable I will just copy the program to a new name and start working on that as my new 'release candidate'. But I don't have a system for generating actual releases. Which means I also don't have a good system for rolling back to previous versions. When I go back to fix a bug or add a feature to an older project, it's very hard for me to remember which one of these version files my device is currently running, and which ones are unstable, and so I don't know which one to work on.

I have only a handful of small programs to keep track of, but if I continue to work with AVRs my code base will continue to get bigger and so I would like to start out on the right foot, rather than have to migrate to something later.

I have heard of things like SVN, git, and so on. I gather people used them for software projects but I don't know how they work and I don't know if they make sense for a "one-man shop" which MIGHT expand in the future. I develop on linux and use vi if that makes any difference.

I would be interested in hearing what other people do to keep track of code and code versions, even if it's just a naming scheme. Any advice is appreciated.

Tags:

AVR Microcontrollers, megaAVR and tinyAVR
Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Mar 5, 2012 - 05:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I have heard of things like SVN, git, and so on. I gather people used them for software projects but I don't know how they work and I don't know if they make sense for a "one-man shop" which MIGHT expand in the future. I develop on linux and use vi if that makes any difference.

You'll get as many answers as you get posters but I'll start the ball rolling by saying that I personally think SVN is great for small AVR projects if you just want to have the ability to roll back to any revision or maybe diff one of the source files between two revisions to remind yourself what you changed.

I set it up for an AVR project recently but this was on Windows where I also have the luxury of using Tortoise as a GUI wrapper for it.

I just checked synaptic in Ubuntu and see there is a repository version of Tortoise for Mercurial (and alternative to SVN) but not a copy for SVN - which is a shame. On the other hand I've heard people who've used both SVN and Mercurial say they prefer the latter so it may be worth a look anyway?

BTW as your post has little to do with ASF I'll move this thread to AVR Forum where it'll get more visibility as I'm sure there must be a number of one-man-shop AVR programmers who'd also like to consider a revision control system of some sort.

Source control is one of those things you don't know the utility of until you start to use it and then, when you do, you wonder how you ever managed without it!

PS forgot to say that on Linux I have used kdesvn as a graphical front end to SVN. It's not as "slick" as Tortoise (IMHO) but was quite manageable.

EDIt: searching a bit turns up RabbitVCS: http://www.harecoded.com/tortois... the author of that article is a big fan of Tortoise on Windows (like me) and says RabbitVCS comes close to Tortoise+SVN so is definitely worth a look (well I'm going to anyway!). (wonder why "rabbit"? It's usually "hares and tortoises" that are compared!)

Top
ArnoldB
ArnoldB's picture
Level: Raving Lunatic
Joined: Thu. Nov 29, 2007
Posts: 3188 View posts
Posted by ArnoldB: Mon. Mar 5, 2012 - 05:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
apt-get install rapidsvn

or really just use the command line.

Stealing Proteus doesn't make you an engineer.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Mar 5, 2012 - 05:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sweet!

I looked at RabbitVCS but as it's a Gnome/Nautilus app and I run Kubuntu (the KDE based one) it was going to pull in about 50 Gnome related things I didn't need to I've parked that for the time being.

Top
meteor
meteor's picture
Level: Hangaround
Joined: Sat. Dec 11, 2010
Posts: 311 View posts
Posted by meteor: Mon. Mar 5, 2012 - 06:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For my 1-man projects (where I'm the only one editing the source code), I simply use the venerable 'RCS' (Revision Control System, by Walter F. Tichy). Since, like me, you're conveniently running a Linux system, simply try 'man rcsintro' for a nice introduction. Basically, you just create a directory named 'RCS' in your source code directory and then use commands to check code into and out of that simple repository. I use Emacs as my editor and there are hotkeys for all major 'vc' (Version Control) operations, so it's trivial for me to check code in/out and do code 'diffs' directly from Emacs. I would suspect that something like that might be do-able in the 'vi' editor, but I've been an Emacs guy for over 20 years now and only use vi when I have to. :wink: (No offense!) :)

Of course, in a shared environment, where multiple people might be accessing the code, RCS is essentially obsolete. In such cases, there are many options, most of which you've undoubtedly heard about (git, Mercurial, SVN, CVS, etc). I'll leave it to others to debate the finer points of those systems.

The advantage of RCS is that it's simpler (less to learn and be confused by, since you don't need much complexity in a 1-man operation) and is probably already on your GNU/Linux system (although some of the others are probably already on your system too). The downside of RCS is that it won't scale well with an expanding (multi-access) operation.

Bottom Line: Any version control system is better than none.

Hope that helps a little....

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Mon. Mar 5, 2012 - 07:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Subversion (SVN) for me, at the moment.

AVR Studio 5 and Atmel Studio 6 (if you use one of those) have plugins for SVN. Search here for "AnkhSVN". This allows you to do many of the frequent SVN operations from within Studio.

Personally, I'm (slowly) trying to move towards one of the "distributed revision control" systems, just for learning something new and that they do allow more flexibility since they demand "less persistent contact with the server". I.e. doing a branch needs something to do it from, but from there you can detach from that source and commit to your branch (assuming it resides e.g. on your local machine) etc, and only later re-establish contact with the source of the branch to re-integrate your work. For e.g. Subversion this is not that easy. The three dominating distributed systems as per my observations are (in alphabetical order) "Bazaar" ("Bz"), "Git" and "Mercurial" ("Hg"). I'm on my way to the latter.

All three, and of-course Subversion, have nice Windows Explorer plugins so that you get context menues in Windows Explorer to do the operations. They all have names containing "Tortoise" (e.g "TortoiseSVN").

For Subversion the Subversion book is mandatory IMO, and it is quite readable. Available free as a PDF.

The gate to subversion is here: http://subversion.apache.org/
TortoiseSVN: http://tortoisesvn.tigris.org/

As Cliff says, there will be many opinions. If you value mine then Subversion is a good starting point. Apart from being designed with some sound principles (again IMO) one advantage with Subversion is that the user base is huge, so getting help should be relatively easy.

Regardless of what RCS you choose there will be an initial learning curve, and likely some frustration before you have gained buoyancy. But as has been stated above, the rewards will eventually be large.

HTH!

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: Mon. Mar 5, 2012 - 07:58 PM
Top
BetterSense
BetterSense's picture
Level: Wannabe
Joined: Mon. Jan 24, 2011
Posts: 84 View posts
Location: Dallas
Posted by BetterSense: Mon. Mar 5, 2012 - 07:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe I will give RCS a try. Then when my brain is used to using a revision control system, I will try to tackle git. In case I would like to open source my code and put it on the web (something I've considered doing), it would probably be good to learn something like git rather than just putting a .zip on my website.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Mon. Mar 5, 2012 - 08:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

trying to move towards one of the "distributed revision control" systems,

I can see the attraction when there are several developers split across the internet. But for local one-man, one-AVR-project use I'd have thought the one that's easiest to use and with best GUI integration would win the day? I believe that is SVN (and preferably Tortoise on Windows).

One nice thing about SVN (when used with Tortoise) is how you can create a repository over the top of a directory tree of existing files. Just create an empty repository and check it out over the top of that file tree (accept the warning about "there are already files") then [Add] the existing ones back into the newly created repository.

I keep threatening to write a small tutorial about one man use of SVN but it's actually quite complex setting up the usage scenarios to show all the things you might want to do. Maybe one day.

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Mon. Mar 5, 2012 - 08:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I can see the attraction when there are several developers split across the internet. But for local one-man, one-AVR-project use I'd have thought the one that's easiest to use and with best GUI integration would win the day?

Cliff!
Let's say you work on several different machines. For SVN this implies a server. Now you decide to go away for a few days, taking one development computer with you so you update your SVN Working Copy. The work you want to do on the road is fairly elaborate so you want to commit now and then - only it turns out that where you are going you have no connectivity to your server.

Enter distributed a RCS. You still have a server as your topmost "upstream" repository. The difference from SVN is that each "working copy" is it's own repository that you can commit to. While your unconnected to the server you can still commit and then ask things like "what did I change before lunch" or do things like "that spike was just crap, take me back to 9 o'clock".

Another way to look at is is to say that each such "working copy" (which actually is a repo, remember?) is a branch. And just like in subversion you can branch from a branch, so when you get that idea while being in the outback you can say "OK, it's a bit on the edge, but I still ant to test that idea so I'll just branch out". If it fails - ditch that branch. If it turns out good you reintegrate "upstream" to the working copy you made just before leaving home/office.

As you've hinted at above you can actually accomplish this, sort of, in Subversion. But:
1) It's "a trick" and a bit complicated to accomplish, and
2) If you actually decide to reintegrate you will loose the revision history in the "branch of the branch"

In a distributed RCS this "Modus Operandi" is at the core of how it works, ad the operations in the distributed RCS support such M.O.

It's been a while since I used TortoiseHg, but AFAICR it was just as well integrated as e.g. TortoiseSVN.

All of this should in no way be interpreted as an argument against Subversion. I've been using it for the last eight years or so and have given Subversion courses on numerous occasions - I'm definitively a fan! (I suppose some people will be just content with what Subversion offers - and what it offers is very good: Stable, proven yet not outdated. A few very nice principles - once you get them you know "how Subversion was thought out" and you will be very confident when using it.) I'm just trying to set the record straight re distributed RCS'es - they support distributed and "detached" work, but this scales down to one-man on one machine work just fine. Several of them can also create branches from SVN repos, IIRC.

Quote:
One nice thing about SVN (when used with Tortoise) is how you can create a repository over the top of a directory tree of existing files. Just create an empty repository and check it out over the top of that file tree (accept the warning about "there are already files") then [Add] the existing ones back into the newly created repository.

Or just use the Import operation.

Quote:
I keep threatening to write a small tutorial about one man use of SVN but it's actually quite complex setting up the usage scenarios to show all the things you might want to do. Maybe one day.

Ditto. (Let's agree to talk before any one of us starts out, OK?)

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]

Top
damien_d
damien_d's picture
Level: Resident
Joined: Mon. Dec 15, 2008
Posts: 923 View posts
Location: Brisbane, Australia
Posted by damien_d: Mon. Mar 5, 2012 - 08:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

+1 Subversion.

Multi-platform. Free. Easy to use. Pick any three!

(Seriously, even our non-technical people use it at work!)

-- Damien

Top
chartman
chartman's picture
Level: Resident
Joined: Thu. May 1, 2003
Posts: 688 View posts
Location: Fleet Hants UK
Posted by chartman: Mon. Mar 5, 2012 - 08:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ultra simple for me, but it works...(all assembler). I have, eg Code_v1.5.asm
In my eeprom I put v1.5
Where possible, I output V1.5 from Txd on power up...
Then I go back to my v1.5.asm if it needs modifying.
I get tied up with device physical addresses/subaddresses and frequencies so it's important to be able to read back the version info.
One downside is if a CPU dies, I'm a bit screwed...but I have a paper trail backup as a last resort..

Top
sambrown
sambrown's picture
Level: Hangaround
Joined: Tue. May 24, 2011
Posts: 306 View posts
Location: Berlin
Posted by sambrown: Mon. Mar 5, 2012 - 09:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with clawson, you will get more different opinions on that than answers.
svn has some major restrictions but it's free, open source and quite easy to set up.

RabbitVCS (frontend) sucks since it badly slows down nautilus.

svn on the command line is most functional for me, you may give it a try

-sb

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Mar 5, 2012 - 09:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having just had Subversion explode on me for the nth time (this time for good - had to restore the database from a backup even though I was committing to a file repository located on the same machine) I'd suggest Git or something else more stable. Git is almost universally better than SVN, doesn't explode as often, and has some great merging facilities you'll probably need in the future.

- Dean :twisted:

(Just grumpy because I would have lost two days work if I hadn't got a bad feeling and backed up both SVN and local copy before trying to commit)

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Mon. Mar 5, 2012 - 09:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Let's just say that mine and Deans experiences differs substantially...

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]

Top
meteor
meteor's picture
Level: Hangaround
Joined: Sat. Dec 11, 2010
Posts: 311 View posts
Posted by meteor: Mon. Mar 5, 2012 - 09:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

BetterSense wrote:
Maybe I will give RCS a try. Then when my brain is used to using a revision control system, I will try to tackle git.
I think that's a good plan. Not to discount in any way the excellent advice that the other folks are providing here, but I'd hate for you to be overwhelmed by the complexity in the more sophisticated revision/version control systems out there. And if you learn (the simple Tichy) RCS, the basic concepts will transfer nicely to other systems.

If you do decide to try (the Tichy) RCS with vi, you might want to Google for 'rcs.vim' and 'rcsdiff.vim', which seem to be useful add-ons to the 'vim' editor to ease interaction with the Tichy RCS system (where the controlled files are stored simply as 'RCS/{filename},v').

Whatever route you take, good luck!

Aside: Personally, I've never seen the use for a GUI for revision/version control systems, but I understand and respect those who prefer that. IMHO, as long as the system integrates well with your favorite editor (which is a strong preference for me), a GUI is irrelevant. For example, in Emacs, with absolutely no effort on my part, I can see the file's revision number and whether it's checked out of RCS or not, all in the ever-present status bar. But, of course, "different strokes for different folks".

Edit: Just noticed that Wikipedia has an article on the venerable Tichy RCS.

Top
BetterSense
BetterSense's picture
Level: Wannabe
Joined: Mon. Jan 24, 2011
Posts: 84 View posts
Location: Dallas
Posted by BetterSense: Mon. Mar 5, 2012 - 10:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I'm playing around with git in a fake repository now, and it seems fairly simple that I just run "git commit -a" when I want to commit changes, and then I can type a message in about the changes I made. This will help me when I come back to a project after months. I assume that I can then somehow roll back to previous versions (i.e. the last one with a message indicating it worked) and fork versions off and stuff, but I haven't learned how to do that yet. The thing that's new is that I'm not getting any different files..I only have one version of all the files in my directory, but I guess the .git directory has all the magic that lets me revert stuff.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Mon. Mar 5, 2012 - 10:07 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The thing that's new is that I'm not getting any different files..I only have one version of all the files in my directory, but I guess the .git directory has all the magic that lets me revert stuff.

Yes, that's how revision control systems work - you have all the revisions stored in a special database, and you only see a "working copy" of a specific revision.

Here's an example, this is my LUFA project Git:

http://github.com/abcminiuser/lu...

Here you can see three folders; "trunk", "tags" and "branches". The former contains the latest working code, the "tags" directory contains tagged revisions (so people can refer to a specific revision with a specific release name) and the latter contains side-versions of my project where I can develop features in parallel.

You can click on the "Commits" button here (also a feature of your VCS GUI or command line, which shows you this:

https://github.com/abcminiuser/l...

Allowing you to view all the changes made between revisions. You can compare (or "diff") a file against an older revision, revert it to the version stored in the database, undo changes and a bunch of other neat stuff. Clicking on a revision shows the detailed changeset:

https://github.com/abcminiuser/l...

So you can see all the changes made in that revision.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Mar 6, 2012 - 10:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Let's say you work on several different machines.

Do people do that then? If they do why don't they buy a laptop and carry it round with them? It takes me months/(years?) to get a new PC setup the way I like and with all the tools I rely on - the idea of having to do this multiple times would be a nightmare!

Quote:

better than SVN, doesn't explode as often,

I'm working with about 100 other engineers on a 20,000 source file project hosted in SVN - we don't see any major problems or "explosions"?

The only problem I've had (because my link to the SVN server is across two VPNs and often suffers "odd breaks" in the middle of operation) is that sometimes a "check repository" tells me I'm up to date for one module when I'm not.

Top
svofski
svofski's picture
Level: Raving Lunatic
Joined: Sun. Jun 26, 2005
Posts: 3126 View posts
Location: St.Petersburg, Russia
Posted by svofski: Tue. Mar 6, 2012 - 11:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use Mercurial (hg) for my personal stuff. Git seems to be very popular too, but it appears to be terribly complex even for the most basic use. -100 to svn as an anachronism that I have to suffer at work daily.

The Dark Boxes are coming.

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Tue. Mar 6, 2012 - 11:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Quote:

Let's say you work on several different machines.

Do people do that then?


I do.

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]

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Mar 6, 2012 - 11:49 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wouldn't you just VNC and/or VPN from one to the other so at least the environment remains the same?

Top
svofski
svofski's picture
Level: Raving Lunatic
Joined: Sun. Jun 26, 2005
Posts: 3126 View posts
Location: St.Petersburg, Russia
Posted by svofski: Tue. Mar 6, 2012 - 11:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Quote:

Quote:
Let's say you work on several different machines.
Do people do that then?

I do.

I do. Because it's kinda cool that you can unroll all your environment in just a few commands. I enjoy that.

The Dark Boxes are coming.

Top
jgmdesign
jgmdesign's picture
Level: Moderator
Joined: Mon. Mar 19, 2007
Posts: 17092 View posts
Location: Long Island New York
Posted by jgmdesign: Tue. Mar 6, 2012 - 11:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am with chartman. I put the revision in the eeprom and spit it out when a certain set of i/o pins are connected to vcc or ground on powerup. Crude but it works.

E-paper trail as backup.

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

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"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, RSLogix user

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Mar 6, 2012 - 12:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I put the revision in the eeprom

How on earth do you store all the project source files in a small EEPROM? (are you talking about a different kind of "revision control" compared to the rest of us? :?)

Top
MartinM57
MartinM57's picture
Level: Resident
Joined: Thu. Dec 15, 2005
Posts: 842 View posts
Location: Bristol, UK
Posted by MartinM57: Tue. Mar 6, 2012 - 12:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Any suggestions for a one-man, one machine, CVAVR (with multiple projects of course), Windows 7 developer with zero ability to use/install anything *nix-like?

Top
svofski
svofski's picture
Level: Raving Lunatic
Joined: Sun. Jun 26, 2005
Posts: 3126 View posts
Location: St.Petersburg, Russia
Posted by svofski: Tue. Mar 6, 2012 - 12:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Tortoise* tools (TortoiseSVN at least) are known to be very user-friendly on Windows.

The Dark Boxes are coming.

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Mar 6, 2012 - 12:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Tortoise* tools (TortoiseSVN at least) are known to be very user-friendly on Windows.

+1

Basically this was my point above - I can't really think how it could be presented any easier or more obvious than the way Tortoise does it.

In the picture a normal Explorer window shows icons against each file (and directory) to show its status. Blue question mark is a file in the directory that SVN does not know about. Green tick means it's the same as the local repository base while a red exclamation mark means it's been locally edited but not committed yet.

On the context menu you can choose which SVN options are on the top level and which are in the sub-menu. I've elected to have the important things like "update", "commit", "diff", "show log", "check mods" at the upper level with the lesser used functions still in the secondary menu.

This integration with Explorer is what makes the thing so easy to use. By the icons you can immediately tell what is version managed and all the things you want to do are one two clicks away.

In the second picture you can easily spot the three directories that are under SVN control.

Attachment(s): 

Image icon Very easy/obvious well integrated software interface
Image icon Three directories are obviously under SVN control

Top
chartman
chartman's picture
Level: Resident
Joined: Thu. May 1, 2003
Posts: 688 View posts
Location: Fleet Hants UK
Posted by chartman: Tue. Mar 6, 2012 - 01:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
How on earth do you store all the project source files in a small EEPROM? (are you talking about a different kind of "revision control" compared to the rest of us? )

Looks like it... I have all the versions on my PC stored as projects, progname V1.0, V1.1 etc and the Vx.x stored in EEPROM.I don't have lots of files that can all have different version numbers that i have to pick and chose to get the right 'build'.

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Tue. Mar 6, 2012 - 02:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Any suggestions for a one-man, one machine,

I would still go for Subversion - but as can be seen above I am a great Subversion fan. Dean will think differently, but he seems to have gremlins in his Subversion machine. :wink:

On the serious side: Do not for a second think that a RCS will releive you from taking backups. On the contrary - you now need to back up the repository. Regularly.

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]

Top
Bingo600
Bingo600's picture
Level: Raving Lunatic
Joined: Sun. Apr 25, 2004
Posts: 4087 View posts
Location: Denmark
Posted by Bingo600: Tue. Mar 6, 2012 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@cliff

I use rapidsvn on linux as the gui frontend

/bingo

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Mar 6, 2012 - 03:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yup, after Arnold mentioned it I downloaded it and gave it a go with one of my existing repo's. In effect it's very like kdesvn that I already have (and use from time to time when I have Windows problems) but neither approaches the shell integration that Tortoise offers. This is one of the few arguments I can find in favour of using Windows!

Top
svofski
svofski's picture
Level: Raving Lunatic
Joined: Sun. Jun 26, 2005
Posts: 3126 View posts
Location: St.Petersburg, Russia
Posted by svofski: Tue. Mar 6, 2012 - 04:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
This is one of the few arguments I can find in favour of using Windows!

I second that, I have never seen anything like TortoiseSVN on OSX either.

The Dark Boxes are coming.

Top
sambrown
sambrown's picture
Level: Hangaround
Joined: Tue. May 24, 2011
Posts: 306 View posts
Location: Berlin
Posted by sambrown: Tue. Mar 6, 2012 - 05:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

eclipse offers a quite usable svn frontend but nothing is as fast and straightforward as the command line

in the last company I've worked for they did develop a release management system based on pysvn which was definitely the best tool I've ever seen

so if you don't like the open source frontends you may develop your own ;-)

-sb

Top
MartinM57
MartinM57's picture
Level: Resident
Joined: Thu. Dec 15, 2005
Posts: 842 View posts
Location: Bristol, UK
Posted by MartinM57: Wed. Mar 7, 2012 - 10:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

svofski wrote:
Tortoise* tools (TortoiseSVN at least) are known to be very user-friendly on Windows.
So I downloaded, got a bit confused - it seemed that I had to download SVN and install Apache and all that nastiness as well - and then spotted that I could use a Windows directory as the repository.

Spent a few hours playing with it...it seems pretty good. I'll keep going with it. Loads to learn still. I presume that after checking in and out stuff a load of times as you iterate to, say the next formal release, you can choose a point and mark it as a new release - then go back and do an (easy) extract of that release number at any point in the future?

Does the repo every get corrupted just by using it "normally"? I have written a DOS script, on a desktop shortcut, to hotcopy the repo to my DropBox account with datetime in the new directory name (so each backup stays separate) for backup/safety purposes

Thanks for the pointers all - nice one (so far)

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Thu. Mar 8, 2012 - 05:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Does the repo every get corrupted just by using it "normally"?

Who knows what Dean did..

Me, I've been using Subversion in software projects with several tens of developers over years with a proper server, and in setups for one user with a local repo. I've not seen it crash once. (I've seen some trouble with TortoiseSVN updating the icon overlays in some circumstances, but that is another story).

Quote:

Loads to learn still.

I do recommend to download the Subversion book. Very good reading.

Quote:
I presume that after checking in and out stuff a load of times as you iterate to, say the next formal release, you can choose a point and mark it as a new release - then go back and do an (easy) extract of that release number at any point in the future?

Of-course. Either just take a note of the revision and later update your WC to that revision. Or do it by the book: At the release you create a well named tag (in Subversion this is just a copy) and later do a check-out of (or a switch to) that.

As for taking backup copies you might be just fine with copying the repo directory tree as long as it is a file repo (i.e. has an URL starting with "file:///". The alternative, and essential when/if you move to a server, is to use the built in repo-dump functionality.

One note: Subversion promises atomic commits - meaning that either all files in a commit will be stored or none at all, and that a failure of the server in the middle of a commit will not leave the repo in an inconsistent state. You only get this using a server, not for a file:/// repo. (The fact that each commit creates a new revision of the complete repo file system still holds.)

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]

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Thu. Mar 8, 2012 - 06:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Wouldn't you just VNC and/or VPN from one to the other so at least the environment remains the same?

No. I don't VNC/VPN from my private laptop when I'm in at "the datja" to my work laptop at work. For one thing, the latter is turned off at that time.

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]

Top
MartinM57
MartinM57's picture
Level: Resident
Joined: Thu. Dec 15, 2005
Posts: 842 View posts
Location: Bristol, UK
Posted by MartinM57: Thu. Mar 8, 2012 - 08:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks JE

My repo is file based and I used 'svnadmin hotcopy' rather than DOS copying so I should be OK I hope

Book downloaded and Ch 1 read. Some way to go yet...!

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Thu. Mar 8, 2012 - 08:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I used 'svnadmin hotcopy'

Oh. So now I learned something too. I was thinking "svnadmin dump" above, and that does not handle some configuration. This is handled by "svnadmin hotcopy".

A breakdown of the options can be read here: http://wordaligned.org/articles/...

AVRfreaks sure is a nice place, huh?! :D

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]

Top
John_A_Brown
John_A_Brown's picture
Level: Raving Lunatic
Joined: Sat. Sep 20, 2003
Posts: 6143 View posts
Location: Underneath the Cotswolds escarpment, England.
Posted by John_A_Brown: Thu. Mar 8, 2012 - 09:01 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been using SpiderOak for a while now.
While it's maybe not a "proper" version control app., it does keep historical backups, which you can download and compare when things go wrong.
Free up to 2GB, which is a suprisingly large amount when the backups are all stored in "differenced" format.
Usual disclaimers, no connection with firm etc. blah blah blah.

Four legs good, two legs bad, three legs stable.

Top
AJ-Saenz
AJ-Saenz's picture
Level: New Member
Joined: Fri. Nov 4, 2005
Posts: 10 View posts
Posted by AJ-Saenz: Thu. Mar 8, 2012 - 06:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I see recommendations are leaning toward SVN. I would suggest to give git a look. I've used SVN and recently decided to try git for my one-man development. I found git much easier to use and the learning curve for me was much less than SVN was. One thing I like about git is the repository is kept as a directory of files vs. a big binary file. This allows you to view the files even without any git s/w. The one big binary makes me nervous, any slight corruption and your whole repository is toast. I also like that there is only one metadata folder placed in the base of your project directory. SVN places one in the base and in each subdirectory.

The online book http://progit.org/ got me going quick and does a nice job of explaining how it works and how to use it.

There is a Tortoisegit install that you can use to make it graphical as well.
http://code.google.com/p/tortoisegit/

Top
smileymicros
smileymicros's picture
Level: Raving Lunatic
Joined: Wed. Nov 17, 2004
Posts: 6320 View posts
Location: Great Smokey Mountains.
Posted by smileymicros: Thu. Mar 8, 2012 - 06:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use Tortoise SVN on Google Code and the only problems so far have been due to my ignorance. When I first investigated getting a version control system a couple of years ago I found that Tortoise was the easy one while git was the one for coders with dangling credentials. I chose easy. Of course Dean now has me worried so I'm going to add my avrtoolbox directory to my Mozy backup for double protection, just in case. Thanks Dean.

Smiley

Top
UnDromader
UnDromader's picture
Level: New Member
Joined: Thu. Feb 2, 2012
Posts: 17 View posts
Location: Bucuresti, Romania
Posted by UnDromader: Thu. Mar 8, 2012 - 07:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AJ-Saenz wrote:
SVN places one(is reffering at a metadata folder) in the base and in each subdirectory.
that is a false statement. Latest TortoiseSVN is not doing it anymore.

SVN for single user. Stable and small learning curve. You can checkout just a part of a repository - you can combine more parts of the repository in the same directory(as subdirectories) - so is easy to reuse common code(debouncing, custom delay, macros, etc.) and keep it fresh for all different projects.

GIT for multiple users. Still new, greater learning curve, is easier to shoot yourself in the foot. You checkout all repository, but a more flexible ignore files pattern.

Top
smileymicros
smileymicros's picture
Level: Raving Lunatic
Joined: Wed. Nov 17, 2004
Posts: 6320 View posts
Location: Great Smokey Mountains.
Posted by smileymicros: Thu. Mar 8, 2012 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

UnDromader wrote:
SVN for single user...
GIT for multiple users...
Maybe it is a language thing, but SVN is for multiple users. Keeping multiple users from stepping on each others files is a main reason for all version control systems. Am I missing something?

Smiley

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Thu. Mar 8, 2012 - 08:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Maybe it is a language thing, but SVN is for multiple users. Keeping multiple users from stepping on each others files is a main reason for all version control systems. Am I missing something?

SVN sucks - SUCKS - for large usersets. It's merging is atrocious, and many branches result in huge disk space usages.

An example: say you make a branch in SVN, work on a feature, and then want to merge it into trunk, which has had multiple other patches applied to it. Say there's a conflict, and you need to resolve it. Now your merge with main results in a huge changeset where your actual branch changes are obscured by all the merge conflict resolution changes. Git by comparison separates the two so they can be viewed individually.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Mar 8, 2012 - 09:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

SVN sucks - SUCKS - for large usersets. It's merging is atrocious, and many branches result in huge disk space usages.

Not my experience. As I say I'm currently one of about 100 engineers collaborating on a project with the SVN located in another country and accessed across VPN. As for merging I use Kdiff3 (as it works the same in Windows and Linux) and find it's great for use with SVN. YMMV (Dean's clearly does!)

Top
keepcool
keepcool's picture
Level: Hangaround
Joined: Wed. Oct 7, 2009
Posts: 282 View posts
Posted by keepcool: Thu. Mar 8, 2012 - 10:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also use SVN (TurtoiseSVN in fact) in all my personal projects, and the svn command line tools under linux to work in the Cambada code, and yes some times it just blows everything up and there is the need to go pick a back-up, we always though the problems where due to server overload, because the Cambada (and also mine) is stored in a university SVN dedicated server.

Yes branches in SVN is as dumb as copy everything to a new folder and call it branch, the most epic and horrid things when merging for some reason always end up to be mangled makefiles that make strange strange things.

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Fri. Mar 9, 2012 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Yes branches in SVN is as dumb as copy everything to a new folder and call it branch

FWIW I think that is smart. Why complicate things when you can do them simple?

As I said earlier, even a straight-forward commit creates a new copy (a new revision) of the complete repository. (I'n sure you know, but still: No, this does not consume masses of disk space, the FSFS file system used ahndles this quite efficiently by linking to the sources rather than storing them all over again.)

Here are some Subversion "principles" to think about (if you get'em you really know Subversion):
- A COMMIT is a new revision of the complete filesystem in the repo.
- A BRANCH is just a COPY.
- A TAG is just a COPY.
- A merge is a "DIFF-and-apply".
- An UPDATE is a MERGE and rebase.
- A SWITCH is a MERGE and rebase.

The worst thing about Subversion is in the merges, but IMO not like described above. The problem is that (up to 6.4?), if you duringthe lifetime of a branch merged activities from the trunk you had to keep notes on that so that when you where ready to re-integrate your work to the trunk you only picked your own changes in the branch. From 1.5 (?) Subversion takes notes (in the form of SVN properties) of merges to a branch, and has included a --reintegrate switch to MERGE to do the merging back to the trunk. Maybe it's just me not having gotten accustomed to that yet, but I am not really on quite friendly terms with that yet. Details on demand..

Re disk consumption I am not of the impression that braching takes up load of disk space. As I said, the FSFS file system should be quite smart about this. Exception: Binary files.

Re performance for large groups, I've been at places where we where several tens of developers working against the same repo and server and it performed just fine.

Re conflict resolutions - if they have to be made I really want to be able to see them in the revision history. For me that is kind of the point with revision control.

Finally I wonder if some of the sound working rules have been used in the cases cited in the critique above: E.g. where merges made with a WC as the target? You can target a MERGE directly to the repo, but that is something I would definitively not recommend. When doing a merge, I always try to follow this flow:

1. Make sure that the WC that will be the target for the MERGE is "clean both ways" (UPDATEd and noting unCOMMITed).

2. Merge with the WC as the target.

3. Resolve any conflicts.

3. Test that everything went well by building and smoke testing. If it didn't you can do small fixes and loop to 3. If it wen really bad you can REVERT and loop to 2.

4. Commit the WC. Make sure the commit comment states unambigously what you merged (i.e. source and revisions that was merged), or trust Subversions mechanism for reintegration.

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]

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Fri. Mar 9, 2012 - 09:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

FWIW I think that is smart. Why complicate things when you can do them simple?

An ASF source checkout is around 700MB - of source code. Having to hit the server for everything is slow, and with bugs resolved in branches that adds up to a LOT of disk space used on the server for all our developers.

A tag should be nothing more than literal revision tag, like Git does it - why make a copy when it is just a revision reference?

Conflict resolution should result in TWO changesets that are committed atomically (again, like Git I hear) so you can see what was changed to resolve the conflicts, and what was changed in the actual branch. This was a nightmare for me when we changed the ASF license text, which resulted in my branch changes being the equivalent of "cat `find -name *.c -o -name *.h`" rather than the actual 100 or so changed lines in the branch.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Fri. Mar 9, 2012 - 11:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm still wondering about this huge disk usage. From what I know (and you too, I suppose) files that are unchanged from the previous revision is actually just links kback to that revision (and so on...). So it's not like you up the repos size with 700 MB when you branch. Right?

No, it's not a non-cost. The links cost, but I am not sure how much. I might do some experiments during weekend..

Quote:
Conflict resolution should result in TWO changesets that are committed atomically (again, like Git I hear) so you can see what was changed to resolve the conflicts, and what was changed in the actual branch.

Interesting! How does Git solve separating them? Do you need to commit the branch changes first and then do the conflict resolution? What happens if you decide to back uot of the merge because of things you see while resolving conflicts? (Those are rethorical questions, but I hope you can understand what I am wondering about re Git in this field. Honest question!)

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]

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Mar 9, 2012 - 11:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
find -name *.c -o -name *.h

Is

find -name *.[ch]

not easier?

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Fri. Mar 9, 2012 - 11:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I'm still wondering about this huge disk usage. From what I know (and you too, I suppose) files that are unchanged from the previous revision is actually just links kback to that revision (and so on...). So it's not like you up the repos size with 700 MB when you branch. Right?

Indeed, but developers are changing files all the time and the disk space is non-trivial with 100+ active branches (one per bug) at once.

Quote:

Interesting! How does Git solve separating them? Do you need to commit the branch changes first and then do the conflict resolution?

I don't know first hand, but the was it was described to me was something like that - you end up with two changesets for the one commit, one for the conflicts and one for the actual changes.

Quote:

Is
Code:
find -name *.[ch]

not easier?

It is indeed, the reason I wrote the above is that I am an idiot and wasn't aware that was possible. Neat!

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Fri. Mar 9, 2012 - 11:57 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you end up with two changesets for the one commit

OK, that actually answers my question! Git knows about what was merged and what was conflict resolution.

For subversion a changed WC is a changed WC. At commit the SVN CI command does not in any way know who/what did what changes to the WC.

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]

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Mar 9, 2012 - 12:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Neat!

Until you want to find *.cpp and *.h !

In that case -regex is possible but, to be honest, I'd just stick with -or:

find . -name *.cpp -or -name *.h

Top
UnDromader
UnDromader's picture
Level: New Member
Joined: Thu. Feb 2, 2012
Posts: 17 View posts
Location: Bucuresti, Romania
Posted by UnDromader: Fri. Mar 9, 2012 - 12:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

smileymicros wrote:
UnDromader wrote:
SVN for single user...
GIT for multiple users...
Maybe it is a language thing, but SVN is for multiple users. Keeping multiple users from stepping on each other files is a main reason for all version control systems. Am I missing something?

Smiley


No Smiley you don't miss anything, but I have made a pro/cons score for both source control engines and exposed my conclusions.
You can use SVN with a team of over 50 people, but a good discipline is required (enforced by an automated testing system, is not enough to resolve merging conflicts, the most expensive conflicts are at logical level).
Also you can use GIT as single user, but the gain over SVN is minimal(the distributed part is not adding any gain) and the loss is somehow great (the tips about keeping in the same directory more subdirectories linked to different paths to the repository - or even other versions of the same paths - mainly to "access" code shared between projects).
Dean in about 7 years of SVN use I didn't had problems with the repository (few different SVN server setups along the way). My projects are not trivial (over 60000 lines of code). As for the occupied space I don't really think that today is an issue to get 2 HDD of 1.5 TB and put them in mirror. To give you a better picture of git/svn confidence: I am using git for over 2 years now, and just for git made a git panic command (in my powershell profile) that will make an dated archive from my current folder.

Last Edited: Fri. Mar 9, 2012 - 11:33 PM
Top
Magister
Magister's picture
Level: Hangaround
Joined: Wed. Aug 6, 2008
Posts: 151 View posts
Location: Montréal, QC
Posted by Magister: Fri. Mar 9, 2012 - 01:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess I am like a lot of people here, I am using TortoiseSVN in Windows with a local repositery, very easy to use, and to backup.

I tried TortoiseCVS but couldn't find a free version or how to use a local folder for repositery, after trying a few hours I trashed it to use SVN instead.

Top
mnehpets
mnehpets's picture
Level: Resident
Joined: Wed. Nov 9, 2011
Posts: 963 View posts
Posted by mnehpets: Fri. Mar 9, 2012 - 08:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:

A tag should be nothing more than literal revision tag, like Git does it - why make a copy when it is just a revision reference?

Although the command you use for tagging is "svn copy", it's actually implemented as a revision reference. Look:

$ svn log -v -r1242838 http://svn.apache.org/repos/asf/subversion/tags/1.7.3 
------------------------------------------------------------------------
r1242838 | hwright | 2012-02-11 03:16:17 +1100 (Sat, 11 Feb 2012) | 1 line
Changed paths:
   A /subversion/tags/1.7.3 (from /subversion/branches/1.7.x:1242825)
   M /subversion/tags/1.7.3/subversion/include/svn_version.h

Tagging release 1.7.3 with svn_version.h matching tarball.
------------------------------------------------------------------------

It's only when you view or checkout that pathname do you see the expansion into the file tree at the target of that reference. In that sense, a "svn copy" is more like a symlink.

$ svn ls -r1242838 http://svn.apache.org/repos/asf/subversion/tags/1.7.3 
BUGS
CHANGES
COMMITTERS
INSTALL
LICENSE
Makefile.in

- S

Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5208 View posts
Posted by skeeve: Fri. Mar 9, 2012 - 09:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

Neat!

Until you want to find *.cpp and *.h !

In that case -regex is possible but, to be honest, I'd just stick with -or:

find . -name *.cpp -or -name *.h

Don't you mean
find . -name \*.cpp -or -name \*.h

How about

find . -name '\*.{cpp,h}'

What is WC?

Iluvatar is the better part of Valar.

Top
alank2
alank2's picture
Level: Raving Lunatic
Joined: Thu. Jul 16, 2009
Posts: 2917 View posts
Posted by alank2: Sat. Mar 10, 2012 - 12:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Everyone,

Ok, I suppose I'm in the "dark ages" of source code version-ing. I've never used a tool like this, and for a single developer situation like I am in, if I'm going from 1.00 to 1.01, I may copy the file myprog.c to myproc.100 before modifying it. Then again, I may not.

Is the added complexity of a SVN and backing it up, keeping track of its database, etc., worthwhile? Perhaps I just don't know what I am missing...

Thanks,

Alan

Autoprogrammer:

https://www.avrfreaks.net/forum/wts-standalone-pdiisp-auto-programmers

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sat. Mar 10, 2012 - 06:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
What is WC?

Working Copy. (Subversion terminology.)

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]

Top
damien_d
damien_d's picture
Level: Resident
Joined: Mon. Dec 15, 2008
Posts: 923 View posts
Location: Brisbane, Australia
Posted by damien_d: Sat. Mar 10, 2012 - 08:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:

Is the added complexity of a SVN and backing it up, keeping track of its database, etc., worthwhile? Perhaps I just don't know what I am missing...

Without doubt.

What might change your mind is how is integrates with trac (free) and fisheye ($10) in order to see the differences between versions and branches.

Other SCM systems are similar.

-- Damien

Top
MartinM57
MartinM57's picture
Level: Resident
Joined: Thu. Dec 15, 2005
Posts: 842 View posts
Location: Bristol, UK
Posted by MartinM57: Sat. Mar 10, 2012 - 09:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alank2 wrote:
Is the added complexity of a SVN and backing it up, keeping track of its database, etc., worthwhile? Perhaps I just don't know what I am missing...
As a 3-day old user of TortoiseSVN with a file-based repository on Windows 7...I don't really know how I managed without it. Every time I get a new feature working in the code (which may take a few iterations of the WC files) then a single RMB click on "SVN Commit..." for the WC folder and I know I have a safe copy (version-controlled safe, rather than back-up safe) that I can always go back to (with one click) and start out again

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sat. Mar 10, 2012 - 10:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI: https://www.avrfreaks.net/index.p...

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]

Top
John_A_Brown
John_A_Brown's picture
Level: Raving Lunatic
Joined: Sat. Sep 20, 2003
Posts: 6143 View posts
Location: Underneath the Cotswolds escarpment, England.
Posted by John_A_Brown: Sat. Mar 10, 2012 - 01:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Been following this thread with interest, and just installed TortoiseSVN under Win 7 64.
Since I have been using(fighting?) Studio 5 for a while now, I have to ask if there are any gotchas associated with Studio 5's weird(to me, at any rate) habit of placing files in sub folders according to some unknown(again, to me) rule. Or indeed the optional practice of linking to files, rather than copying them, when adding sources.
I am concerned that retrofitting TortoiseSVN to my existing projects might cause me some grief, any reassurance welcome!

John

Four legs good, two legs bad, three legs stable.

Top
JohanEkdahl
JohanEkdahl's picture
Level: 10k+ Postman
Joined: Wed. Mar 27, 2002
Posts: 26988 View posts
Location: Lund, Sweden
Posted by JohanEkdahl: Sat. Mar 10, 2012 - 03:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Or indeed the optional practice of linking to files, rather than copying them, when adding sources.
I am concerned that retrofitting TortoiseSVN to my existing projects

Well, storing the links in a subversion repository makes little sense. Either copy the files, rather than accepting the default link behavior, when adding a file to Atmel Studio. Or go the whole way and build files that are shared between projects into a project of their own that produces a library rather than an executable - all source files are proper in projects, no links anywhere. (Now you have to ponder how to organize your repository, but that is another thing.)

Aside: I really, really, really wonder what went on in the head of the Atmel person that decided that link would be default. I guess they realized that when people add ASF stuff to their projects they will be close to impossible to have up to date when a new ASF version comes out. They should have made ASF a proper library, I suppose.. (But then again, I'm not an ASF user at all so I might be totally off..) Or that person made the descision after having been treated to all that free booze by the Microsoft guys. :evil:

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]

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sat. Mar 10, 2012 - 06:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Without doubt.

+1
Quote:

with trac (free)

We use that corporately (and CDash and Cmake). All great tools.

Top
BetterSense
BetterSense's picture
Level: Wannabe
Joined: Mon. Jan 24, 2011
Posts: 84 View posts
Location: Dallas
Posted by BetterSense: Sun. Mar 11, 2012 - 01:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well I started with git. Since I'm just working by myself, it's pretty straightforward. I just run 'git init' in my project directory and then 'git add .' to add everything. At this point I just do a commit whenever I think it makes sense to 'save my progress'. I will have to learn about branching when it comes to that.

Should I create a git repo for each "project" or should I just create one master git repo for all my programs, even ones which aren't related?

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Sun. Mar 11, 2012 - 12:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Should I create a git repo for each "project" or should I just create one master git repo for all my programs, even ones which aren't related?

Remember the point about backing up repos - do you want lots of small ones or one big one? There are +'s and -'s to both approaches.

Top
gchapman
gchapman's picture
Level: 10k+ Postman
Joined: Tue. Jan 9, 2007
Posts: 11992 View posts
Location: Clay County, Texas, u.S.A.
Posted by gchapman: Sun. Mar 11, 2012 - 01:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One advantage of DRCS versus RCS is the repository is copied (it's a backup). If a/the repository is on a NAS that's another backup and another backup via the NAS's easy backup function (onto SD card or USB stick). If open and free(dom) software, free(beer) backup is available on the net.
I have a bit of hard luck with hard drives.

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

Top
John_A_Brown
John_A_Brown's picture
Level: Raving Lunatic
Joined: Sat. Sep 20, 2003
Posts: 6143 View posts
Location: Underneath the Cotswolds escarpment, England.
Posted by John_A_Brown: Tue. Mar 13, 2012 - 06:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hmm.. I have only started to dip my toe in the water here, but the help docs say that the file icons in my working copy folder should have overlays to flag their status - they don't. Am I doing something stupid(apart form trying to teach an old dog...)?

Quote:
You will notice that the appearance of this folder is different from our original folder. Every file has a green check mark in the bottom left corner. These are TortoiseSVN's status icons which are only present in a working copy. The green state indicates that the file is unchanged from the version in the repository.

Four legs good, two legs bad, three legs stable.

Top
abcminiuser
abcminiuser's picture
Level: Raving Lunatic
Joined: Fri. Jan 23, 2004
Posts: 9856 View posts
Location: Melbourne, Australia
Posted by abcminiuser: Tue. Mar 13, 2012 - 06:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Hmm.. I have only started to dip my toe in the water here, but the help docs say that the file icons in my working copy folder should have overlays to flag their status - they don't. Am I doing something stupid(apart form trying to teach an old dog...)?

This could be either:

1) You've installed the 32-bit version of Tortoise on a x64 bit machine (or vice-versa)
2) You haven't restarted since installing Tortoise
3) Your repository is gigantic and Tortoise's caching mechanism hasn't caught up yet

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Top
clawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 99411 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Mar 13, 2012 - 07:24 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The occasion on which I didn't see the icons when I was expecting (which actually lead me to copy a 1GB source tree from one drive to another) was because I later found this - by default "Network drives" is not ticked!

(I kicked myself later when I realised it was a simple as a single tick).

Attachment(s): 

Image icon svnicon.png

Top
John_A_Brown
John_A_Brown's picture
Level: Raving Lunatic
Joined: Sat. Sep 20, 2003
Posts: 6143 View posts
Location: Underneath the Cotswolds escarpment, England.
Posted by John_A_Brown: Tue. Mar 13, 2012 - 11:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
Quote:

Hmm.. I have only started to dip my toe in the water here, but the help docs say that the file icons in my working copy folder should have overlays to flag their status - they don't. Am I doing something stupid(apart form trying to teach an old dog...)?

This could be either:

1) You've installed the 32-bit version of Tortoise on a x64 bit machine (or vice-versa)
2) You haven't restarted since installing Tortoise
3) Your repository is gigantic and Tortoise's caching mechanism hasn't caught up yet

- Dean :twisted:

Thanks, Dean. It was 2).

Four legs good, two legs bad, three legs stable.

Top
John_A_Brown
John_A_Brown's picture
Level: Raving Lunatic
Joined: Sat. Sep 20, 2003
Posts: 6143 View posts
Location: Underneath the Cotswolds escarpment, England.
Posted by John_A_Brown: Tue. Mar 13, 2012 - 11:44 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem I now have is that, after importing an existing project to my repos, and then checking out a working copy to a new directory, I seem to have duplicated files, this is possibly related to my shaky understanding of what Studio 5 refers to as "solutions" and "projects". I've always accepted wherever Studio 5 wants to create new files for my app, because I haven't worked out either:
a) Why it does what it does.
or
b) How to alter its behaviour.

So I always seem to end up with files split over two directory levels. TortoiseSVN seems to have duplicated most of my files in both levels. Studio 5 still works, and builds the app, but I'd like to resolve this sometime.

[Edit] Later that same day: Weirdly, it seems that if I delete all the source files(.C .H and .S) from the "solution" level, but leave them in the "project" folder, Studio 5 finds them all and builds OK. [/Edit].

Four legs good, two legs bad, three legs stable.

Top