RomRaider

Not if they don't exist! https://github.com/RomRaider/RomRaider/network


Make a fork, push them up, press "pull request" button, done. :-)

Your changes aren't visible here, which means you've not published them yet, which means no one, including Dale, can pull them in.

Note, it's polite to rebase your work onto the upstream's work so that it can be cleanly applied. You don't want a situation like this:



Also note that upstream should push all the time and not leave private commits hanging around, otherwise you're making it impossible for the downstreams to be nice to you by rebasing correctly.


It's not safer, and here's why: In order to switch branches or do anything else, you must have a clean working directory. If you are on, say, master, and have a clean directory, then your latest commit is what master refers to. At this point you can simply "git checkout <ref/hash>" and you're not on ANY branch anymore, OMG! :-o :-) You can still make commits, no problem, then you can push those commits to a remote for your friend to pull from with "git push HEAD:refs/heads/newBranchForMyFriend". If it's something that you want to save, you can create a branch label for it "git branch name" and then just go back to master "git checkout master". You're using it in a very stiff way. Years ago when I started, I had a branch for each person whom I was pulling from. Now I only have their remotes, it's much cleaner and more efficient.


This implies that they have access to your box! :-o Or a server setup locally on your box. Having promiscuous boxes everywhere (no pun intended) and/or a server setup on every single box, is, I think, clearly inferior to having a single server setup that the team shares. In any case, that's all a matter of style and preference, the practical side is the same, security implications and excess work aside.

Forking on a remote:



Sharing using remotes:



Clean and scalable :-)


Go for it! :-)

Fred.

In the past people have just sent changes to me and I've incorporated them into the project.

BTW: where in KW are you? I was at Conestoga for three years eons ago and I grew up south of Cambridge.

OK, I see then, this is the central spot to pull changes in. This makes sense since we cannot assume that anyone doing romraider development can see everyone elses machines.



Ya, when I get a chance, maybe I'll start with something small to make sure it does not get screwed up.



Yes, this makes sense too. Fortunately there are not tons of people making commits so rebasing is no big deal




I should probably have added that at work we actually use svn for all 'central' commits so we've just been using git within my team. The git-svn workflow is extremely complicated but we felt that the advantages of being able to easily pull (share) changes from each other was worth using git for.

I almost never 'work' on my local master either. Any work I'm doing is either on one of my personal branches, I tend to keep branches for different tasks, or temporary branch that I use to pull changes from one of the team. You cannot do this at all with svn...

We do not set up servers on every box, and, yes, we all have access to each others machines. This would not work at all if we did not. It's all inside the company network/firewall so I don't see a big problem really.

I'm not exactly sure how it involves excess work..

At any rate, I've digested your diagrams and it makes sense given that we cannot "see" each others changes.

As an aside... I don't feel 'svn branching' is complicated, which I think was mentioned earlier in this thread. I think svn is quite simple actually. To svn a branch is simply a copy of a directory. What makes it complicated in my mind are two coupled issues: that 'people' apply certain principles and concepts to the branching strategy AND developers with commit access cannot make a 'branch' on their own so it's like some sort of unknown world to them. Most people don't realize that if they make a copy of a directory on thier file system then they 'make a branch'... Later, what can also be more complicated, is the merge process if you need to merge from one directory to another, I think git is better and more robust for this. I have almost zero problems merging from one of my branches back to my master.

Yes, now that we use git though, emailing diffs around is not necessary. You simply pull my changes when you feel like it. I have a small change to logger.xml that I could commit if you like.

Aare the logger.xml and ecu_def.xml files incorporated into the definitions threads http://www.romraider.com/forum/viewforum.php?f=8?



Cool. I live in Bridgeport (Kitchener east side) and work in Waterloo for www.ansys.com.

Indeed, this is the normal model of collaboration, regardless of which server service you use (repor.cz, gitorious, github, etc). Security, in terms of "is this what the other intended me to get" is as simple as "Pull this hash: 894894998298h4h3" and if they fetch, and can git show/checkout that hash, they KNOW that they have the exact work that you meant them to have. This even works for private collaboration over the net as you can setup a service using ssh keys that doesn't allow ssh login, only git operations, easily.


Glad you agree! :-)


I disagree that it's extremely complicated, but I agree that it's wholly worth it! I've been git-svn-ing for a long time with great success :-)


It's just a matter of labels. I tend to work on master as I tend to be working on the effective trunk most of the time. When you're on a branch, it should be due to extreme change that would break master, or parallel changes that are unrelated and/or incompatible, etc. If most of your work is branch work, I hope someone else is doing good stuff on the trunk, otherwise where is the project going? LOL.


Extra executions of git <command> <args> over a minimal approach that is possible. I didn't say a LOT of extra work, but extra work, nonetheless.


Yep, it's the standard work flow :-) You're just bypassing the public step because you have a promiscuous environment. It's effectively the same.


Not complicated, but slow, bandwidth and resource intensive, and, as you get to later, complicated to merge back in, in that it's very very manual because SVN <= 1.5 didn't store ANY metadata about origins of branches. What they added later was just a hack/patch anyway.


It sure is, simple and powerless. Also clumsy, slow, fragile, insecure, awkward, inefficient, etc :-)


This is a limitation of your administrator(s), not of SVN. A user with access to the repository as a whole can branch, anyone with those privileges can. I actually prefer a micro structure of root > project/path/of/N/depth > trunk/branches/heads not the traditional root > trunk/branches/heads > project/path/of/N/depth, though both have their benefits and I'm starting to forget, because, to me, SVN is purely a thing of the past.


As a statement, this is false. You likely meant this:


However even that is false, it's only a branch in SVN once the copy has been committed to a place arbitrarily called "branches" whether that be at the root or in a subdirectory for that specific module or project.


Right, because the tree structure is not maintained, the system itself has no detailed knowledge of code history, and the external tools CAN NOT do a good job of faking it for you. Thus it's an entirely manual process, prone to error and slow/lengthy/difficult at the best of times in simple situations. In complex situations it's not uncommon for 2 devs to spend 2 days merging a branch. Contrast that with Linux, where one dev manages the entire merging of 10,000 developers and you start to comprehend the power of git.


Because git DOES have the metadata required and it is mostly automatic, except where it can't be.

As an aside: Some entertaining reading: http://www.flickr.com/photos/sermoa/3425577867/

Did you ever hear an SVN user say "I've been looking forward to merging 8 branches into trunk in a single commit" no, you certainly did not :-)

Fred.

I don't think I understand the question.
Those defs are not part of the repo. That may change in the future once I convert to EcuFlash style rather than the whooping big XML used now.

Looks like they have a broad range of services, interesting.

I'd encourage a separate project, which I think someone else suggested here, maybe merp?

Yes, sorry, my question was poorly worded. What I meant to ask was if the logger.xml and ecu_defs.xml included as part of the romraider checkout are 'consolidated' with the version(s) in the logger and ecu def threads:

Logger def thread: http://www.romraider.com/forum/viewtopic.php?f=8&t=1642
ECU def thread: http://www.romraider.com/forum/viewtopic.php?f=8&t=360

If we commit changes to the romraider versions in git do those changes get incorporated back into the above?


Yep, ANSYS has aquired a lot of software over the years. I work on the fluid dynamics solvers mainly and came from CFX (http://www.ansys.com/Products/Simulation+Technology/Fluid+Dynamics/ANSYS+CFX) when it was aquired. Many of the turbo charger manufacturers use CFX for their designs.

In the context of explaining it to a dozen developers that all think like this about source control:

- it must works seamlessly such that I don't need to even think about it
- I check out a file, make changess to it, rebuild, check it back in
- If I have to learn about anything else regarding source control I do not care and its over complicated

then the git-svn interaction is complicated. It's like a 6-7 step process for those of us using git to get ourselves set up to share code.



Ya, working on the master (effective trunk) is what you would do most of the time. Unfortunately this is completely useless if you need to work on more than one concurrent task and switch back and forth between them. This is very comon when fixing multiple bugs for example. If you want to fix each one in isolation, switching back and forth between working on each, and separately commit the change for each then the only way to do it is with branches. This type of workflow is nearly impossible with svn and is at least achievable with git.



Yes, true enough. Developers are not allowed to branch because of the way our servers are administered.


I was talking conceptually. I don't think it's false that an svn 'branch' is a copy of a directory from one spot in the repository to another.



Yes, fine, you are right, it has to be 'committed'. People are the ones that decide to impose arbitrary concepts like a 'branches' directory to handle this and it could go in any old directory and be called a branch in concept.


LOL. Ya, nobody does this at work... for good reasons. In fact, we find it better to manually manage merging between branches because it is dangerous to automatically do it. No source system in the world can figure out if the changes that get merged make semantic sense. Syntatical maybe.. but definitely not semantic.

The versions in the repository are not up to date and are not kept up to date. They are they from some time in history when the repo was tracking the changes. I think the source repo should be for the application source and the "user" definable files like logger and ecu definitions should be separate. We should not be polluting the application's installation directory with these files, but rather store them in a user directory, that's why their location is a user definable setting within the applications.

For the logger parameters I have a SQL database that I keep up to date with any changes sent to me or for ROMs I've defined. I will eventually have one for the ecu defs as well. The database makes it really easy to import changes and add new parameters and then dump the data out to any file format we wish. The logger DB is quite easy, the ecu defs a little more involved. But the advantage is it allows for some checks and balances plus we can dump it to any format either RomRaider style or EcuFlash style after an update.

The bit highlighted in bold is a fatal mistake bordering on idiotic. I'd rather not have people like that on my team. Source control is as integral to real development as the source itself is. Any interaction with it should be 100% deliberate and by design. Anything else is in close parallel to this: http://pragprog.com/the-pragmatic-progr ... oincidence

This is false, you can do it purely by hash without being on *ANY* branch. Depending on how many you're dealing with and how short your memory is, it may not be practical. Re fixing in isolation, etc, etc, check this link. My point wasn't not to use branches, my point was that in many cases you can simply get away without them and just code. Again, it's just a matter of labels. The underlying tree does not care if you call it late-for-dinner, or any number of other names.


That's exactly what it is, when it's on the server, provided that it's not on the server, and is just on your local disk, it's nothing more than a file system modification.


Fixed. :-p We're having a conversation about something technical with specific language. I will be a stickler for the details. If you're loose with language we're always going to butt heads.


How is it better to manually do something that can be achieved automatically and then checked. Note the full stop, it was a rhetorical question, it's not better.


Of course not, that's what code review and diff review are all about. You don't just do an automated merge and go "great, no conflicts, it must be good, push". You let the automatic merge take place (manually merging conflicts, if any), choose a reference and compare what the current code looks like relative to that. If it actually makes sense, and your developers were talking to each other and being smart about it, then you call it good, and push.

I've gotta ask, if you are that fond of git, why didn't you take the initiative and get it done a year ago when you joined? You seem to have a lot to say on the matter :-)

Fred.

It'd be a very quick commit, just git rm them and be done with it for now.


Wow! That's an industrial approach :-) As much as I hate SQL, I like what you've done :-) How can you migrate to a collaborative model with a database involved? Or do you not want to? Tell us your plans :-)

Fred.

Thanks for the link, I'll have a look.

Most of the developers I work with are not career programmers but generally gradutate school level engineers who prefer to think about numerical algorithms and modelling of physical processes. For such types, having to think about code architecture or source code control, in any further depth than what I describe, is considered a nuisance at best. It's a mostly byproduct of the domain I work in.


I think we are just having a small terminology difference as far as I can tell. My understanding was that a label or hash in git is a branch. Maybe I've understood wrong.


Were we butting heads?


I'm afraid I have not fully explained myself. I've seen cases where teams have made the choice to let 'auto merge' scripts handle the merging without even looking at it... this is completely crazy.


Fair question.. the only answer is time mainly. I really wish I could help our more with romraider development, reverse engineering ECUs etc.. I find it all facinating. My priorities tend to go: family, work, exercise, hobbies (such as this)... In the hobby category I spent a pile of time in the last year and a half retuning my car. So, I need to balance doing that with everything else.

Yes, I agree, if these are not up to date then it might be better to just delete them. The changes I was going to provide simply add a few extra unit types and expressions to some of the logger parameters.

A git branch is simply a pointer to a hash. A hash is not a branch, it's a/the probably-unique identifier of a commit. A commit may be at the tip of a line of dev, or at the root, or somewhere in between. Without the label, though, it's just a commit. "master" is the default label (and branch) for whatever series of commits are when you clone a repo. Just as origin is the default label for the remote that you tend to push to from master. You can ignore all of these labels and work with git raw, checking out commits, pushing commits to remotes as remote-only labels (remote branches), etc, all without ever being on a branch (labeled commit). Tags are different. Tags have metadata as well as a label.

In git all branches are equal, the human distinction of which one is "master" or "trunk" is just that, a human distinction. You have to consider something the main line of development, though, and any other git branch is a branch, in that line of thinking. EG, I'm working on a branch to use Maven 3 to build RR. It's a branch to me because it's not the main line that Dale is working on. When I'm happy with it, I'll rebase it, fixing conflicts, verifying functionality, and push it to a remote branch (from my master) for peer review by Dale and perhaps others. If they accept it, and no further work has gone on, it'll get fast forwarded into official/master. If they accept it and further work has gone on, I'll rebase again, check again, and then send it to official/master. If they reject it wholesale, I'll fork :-)


Perhaps not, but I seemed to be correcting you in pedantic ways a lot :-)


Email this guy the details: http://www.codinghorror.com/

That sounds worse than the china/india outsourcing that I've seen :-)

Fred.