Forking/Branching a Project/Solution

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

Greetings -

 

I've muddled through this once, made a merry mess of things, and would now like to find a better way. Here is the situation.

 

Have a project. It has gotten bigger and bigger, so I decided to break it up into modules.  BUT, I did not want to throw away the old one because I needed some working reference to go back to when (not if) I mucked things up. So, I simply duplicated the solution folder. I then opened the duplicated solution by double-clicking the Studio file (.atsuo, maybe, don't remember for sure). It opened, after LOTS of grinding and gnashing of teeth. Now, the project selector in the opening window of Studio has TWO projects with the same name. 

 

I suppose that I could have just zipped up the archive fork and proceeded on with the changes to the main project, but I have had to go back a good 8-10 times to recheck the original, and having to dig into a zip archive would have been a major pain. 

 

There HAS to be a simpler way, one that allows you to rename the forked project (maybe from XYZ to XYZ2, for example). For example, if it were possible to do "Save As ..." for an entire solution? 

 

Thoughts, suggestions, or "Wagner, you must be blind as a bat, its so simple, right there in ..."?

 

Jim

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

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

are you using version control? i.e github?

 

if not...do it.

Then you can branch and modify to your hearts content without loosing ANY data.

This goes for every project and every developer. If youre not using source control you need to be!

Keith Vasilakes

Firmware engineer

Minnesota

Last Edited: Thu. Oct 30, 2014 - 04:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried Mercurial because there was a client for my Mac, but could not figure out how to make it work.

 

Jim

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

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

Surely there must be a Mac client for SVN? I've used SVN and Git extensively (and MS Sourcesafe previously) and SVN is by far and away the easiest tool to use for tracking changes.

 

A quick Google suggests the Mac choice may be between "Cornerstones" and "versions":

 

http://stackoverflow.com/questio...

 

(actually "Tortoise" on Windows makes SVN so easy/pleasant to use I'd be tempted to use a Windows VM purely so that Tortoise could be used).

Last Edited: Thu. Oct 30, 2014 - 04:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Use github...

SVN isn't worth using

 

Github is Git, it's got proper branching and tagging.

 

If you're going to learn version control learn git

 

Github has good tutorials also.

Keith Vasilakes

Firmware engineer

Minnesota

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

No flame wars over proper version control, please. I forgot that this could be as divisive as "best compiler".

 

One of my challenges is that I am stuck at Mac OS 10.6.8 and a lot of the GUIs require newer OS versions. Some of them require the use of MacPackages for installing, or something named about that, which I have never gotten to work. One is hard coded to use ~\util\bin or such.

 

I have found a git/hg thing called SourceTree that has basically the same gui on Mac and Win and I think that I'll try that. I think that I'd really prefer a distributed system rather than a central repository.

 

Thanks

Jim

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

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

I use Source tree, it's pretty nice.

It works with github too.

And github will do git, or Hg if you want Hg for some strange reason.

 

you really do want a distributed VCS, it makes life way easier.

Learn to commit early and often, it's easier to ignore a commit than it is to try and remember what happened in between commits.

 

The only overhead in a distributed vcs is you have to push to the server,

The advantage is you can work disconnected and just commit at will, then push all the changes in one fell swoop

 

If you switch to Sourcetree / git you can eliminate dropbox you mention in another thread, just push and pull

 

Keith Vasilakes

Firmware engineer

Minnesota

Last Edited: Thu. Oct 30, 2014 - 06:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My vote is for SVN also, I've used it for years and it's by and far the easiest, I did try Git and others but they weren't near as intuitive.

 

Another reason to use SVN is that the AnhkSVN extension for AS allows most of the SVN functionality from within AS.

Happy Trails,

Mike

JaxCoder.com

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

yes git / github is slightly harder, but is a lot more powerful.

having real branching and being distributed are the reasons to use it.

 

You can branch your code, work on it without changing the original code, then merge it back in once it's working.

If you never branch, then it's not worth using of course, but then why use a VCS, just zip it once in a while

Keith Vasilakes

Firmware engineer

Minnesota

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

You can rename solutions and projects.

 

 

 

You can open the original solution/project and save the template.

 

 

 

Then create a new project, and select the template:

 

 

 

Now you have a clone.  I make the new solutions folder be a sibling of the original.  That way, relative paths will be right.  This may or may not be useful for you.    After I make the clone, I rename the solution and project. 

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

ok,

have been tolled to use svn zillion times, but I still work with zip files.

when I start teh day I make a zip and add a time stamp to it, so "JanControl_V0-0-1_20141031_0745.zip" will be de zip names.

If I make more then one zip a day I just change the time stamp. Like for instance when you would be going to change a lot in the file structure I start with making a zip and in between also make a zip on a couple of points were I have compilable and more or less working code.

when I have finalized a version I create a zip with the name "JanControl_V0-0-1_released.zip"

and put all the pre release zips in a new zip, only to not have a shitload of zips. and give that a pre-release name.

or I even throw these zips away if nothing spectacular is changed in the mean time.

 

for me this works, but I am a hardware guy, just changing code for testing purposes and i am 100% sure my code will never be used as such by our FW guys as most of the times I take their code and mangle it till it does what I want it to do, which is most of the times something we definitely do not want to be possible in the field.

 

 

 

 

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

and being distributed are the reasons to use it

How is that an advantage for Jim working alone?

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

for me this works

But how do you tell what you changed between the 17th and the 24th? I assume you have to extract both source trees and then diff between them?

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

clawson wrote:

and being distributed are the reasons to use it

How is that an advantage for Jim working alone?

 

It allows you to use the version control even when you are not connected as it maintains a local copy of the repo.

This does a number of other things things, make it faster, provides 2 backups ( one local, one remote )

 

Not using version control is a lot like not using seat belts, it doesn't matter until you get in a crash.

 

But version control with real branching, aka git, allows you to maintain sanity while developing a new feature or refactoring as you don't destroy the old code, it's right there for you to see.

You can switch back and forth at any time to verify functionality or whatever.

It also lets you look back in time to see what you changed, very helpfull when you realise something broken and you wonde what changed. You can do a blame on the file and see when the change was made, then go look at that commit and figure out why you made it.

 

You can use git from the command line, if youre that kinda guy, or use SourceTree if youre a GUI guy. They both work well.

Do that with zip files

 

I personally actually use all 3 methods, git, svn and zip files.

Git is for code

SVN is for documents, since theres not a lot of branching going on

Zip files for when we have gigabit releases that would choke a VCS, we drop them on a network drive ( note that the code still resides in git )

Keith Vasilakes

Firmware engineer

Minnesota

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

It allows you to use the version control even when you are not connected as it maintains a local copy of the repo.

But SVN does that too - I use a local file:// repo on another drive all the time for local/personal projects

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

sure.. thats the same thing .... :)

 

Keith Vasilakes

Firmware engineer

Minnesota

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

clawson wrote:

It allows you to use the version control even when you are not connected as it maintains a local copy of the repo.

But SVN does that too - I use a local file:// repo on another drive all the time for local/personal projects

It sure does. I think Git is still easier in this case because you can create a local copy of the repo in the same directory as your project with a simple "git init" command (or the GUI equivalent). With Subversion you have to create a separate directory that contains only the repository, and then you have to check out that repository after you create it. You can (but don't have to) do the same with Git (I do when I want to share my repository with someone else or with myself on different computers--it's a bad idea to clone from a repository with a working copy), and you can even create the separate repository directory after you already have a repository in your working copy.

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

A question, being totally unfamiliar with any VC system....

 

Say I have a project with a couple of supporting .c modules and some .h files (and, of course, Studio's project management files).

 

Now, I want to branch this project, changing the whole system of module and header files. I go to a lot of work to modify the project so that the correct modules are used. 

 

Now, just what is it that goes into the VC system? Can you apply this to the whole project, including the management files? Or, is this limited to the .c and .h files? 

 

steve17: thanks for that demonstration of how to change a project name. That totally eluded me!

 

Thanks to all,

Jim

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

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

I do this way too often...

The hard part is figuring out what is generated by the IDE and what you need.

It usually takes a clean and checkout to prove whats needed

 

but you typically put project settings, workspace settings, make files in ti VC.

But leave out display settings ( tab spacing, user name etc )

 

Files can move at will. the better VCS will know the file moved ( well not ALL the time )

 

Oh and in some IDEs aka mplab 8, you have to tell it to use text based project files so you can diff them

Keith Vasilakes

Firmware engineer

Minnesota

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

clawson wrote:

for me this works

But how do you tell what you changed between the 17th and the 24th? I assume you have to extract both source trees and then diff between them?

 

yes I then unzip both to a common space and use a simple tool called winmerge to check out the differences.

 

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

Now, just what is it that goes into the VC system? Can you apply this to the whole project, including the management files? Or, is this limited to the .c and .h files? 

Can we just check you really do mean "branch" in the VCS sense of the word? That is that once you have made the change you want to have two active paths of development. One continuing to follow the old layout of modules/headers and one following the new layout. Or is it simply you want to make a complete change but retain access to the old version just in case you ever need to go back to it? One is linear, one is a "fork".

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

I want to just archive the prior structure, having ready access to it (which would not be the case if it were zipped). It would be nice to be able to have an old version of a module and the new version both open in a code editor (not Studio) to do a side-by-side comparison to see where the new is afu (sorry, "all-f....d-up") compared to the old.

 

So, I really do not know whether fork or branch is the correct term. They sounded synonymous to me.

 

Thanks

Jim

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

Last Edited: Tue. Nov 4, 2014 - 10:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

So, I really do not know whether fork or branch is the correct term. They sounded synonymous to me.

 

Thanks

Jim

At least with git and Subversion there is no concept of "fork". You can make a new "branch", which is just a path of development, at any time and continue working on one or both of the branches independently of each other.

 

If you mess up the branch, you can just delete it and forget it was ever there. The original branch will still have the original version of the code from before you made a branch.

 

With most VC systems you can easily compare any two versions of your code line-by-line to see what was changed between them. You can also see when each line in a source file was last changed and (in case you care to know) who made the change.

 

One cool feature that I like in git (some other VC systems may have it too) is its "bisect" tool; it can be used to quickly pinpoint the exact revision that introduced a bug. You have to tell git about two revisions: a "bad" revision that contains the bug and an older "good" revision that doesn't contain the bug. Git will iteratively check out a revision halfway between the "good" and "bad" revisions (you have to tell git if it's bad or good) until it finds the first "bad" revision. This is a binary search so even with 100 revisions between the good and bad revisions it usually takes only about 7 check-outs to find the first bad revision. The first time I used "git bisect" to find a bug I found the first buggy revision after building and testing only about 4 different versions of the code (there were a dozen or so revisions between the good and bad revisions), and the problem was obvious when I looked at what changed between that revision and the previous one.

Last Edited: Wed. Nov 5, 2014 - 09:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"all-f....d-up"

All forked up? surprise

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

ka7ehk wrote:

I want to just archive the prior structure, having ready access to it (which would not be the case if it were zipped). It would be nice to be able to have an old version of a module and the new version both open in a code editor (not Studio) to do a side-by-side comparison to see where the new is afu (sorry, "all-f....d-up") compared to the old.

 

So, I really do not know whether fork or branch is the correct term. They sounded synonymous to me.

 

Thanks

Jim

 

You want branch.

A fork is a copy, usually by someone else that doesn't have write access to your repo.

So they fork the development and MAYBE they merge your changes into theirs once in a while. But they don't have to. And they never merge their changes bake into yours

 

A branch is expected to be kept up to date with the masters changes on a periodic basis and most likely, but not required, will be merged back into the master when the changes are complete

Keith Vasilakes

Firmware engineer

Minnesota