| ??? 09/09/08 00:41 Read: times |
#158099 - details Responding to: ???'s previous message |
Jan Waclawek said:
What does that mean, particularly? How often do you commit the changes? I commit: a) Whenever a piece of code upon which I am working is "good," meaning that it compiles and builds. It might not be correct yet, but I use a commit log message to indicate that. b) At the end of the day. Do you maintain some sort of documentation via CVS/SVN? In what form, do you try to "help" SVN by documenting in ASCII-based system (such as TeX or some XML-based way)? If by "documentation," you mean change logs, well, that's what commit messages are for, and as such your logs are only as good as your messages. Do you keep also the tools, datasheets etc. (i.e. all the "externalities" of the project) in the repository? No, never. Do you keep CAD design files under SVN? Absolutely. svn has no problem with binary files, although of course diffing them is impossible. All of my FPGA stuff is in the repository. Where do you keep the repositories, locally or on a centralised server, or otherwise? If the server is remote, do you use one single server for all your work? Is that server administered by you or by somebody else? The work server is in the server room. It's a linux box for easy remote access. At home, my svn server is a Mac mini using apache as the server, so I can get to it from anywhere in the world. Do you use Windows? Win9x, perhaps? XP, please. Win9x is deprecated and I don't know anyone still using it. Do your sources span a tree? Or, perhaps, are they scattered in several non-continguous places over the workstation (this for example appeared to be an unsolvable problem when I tried to use SVN, while I had a very good reason for doing so)? What do you mean by "span a tree?" I can think of some use cases brought on by the stupidity of the Xilinx tools that make for "tricky" ways of keeping your data in the repository. Per Westermark said: I don't quite understand what do you mean by "shared machines" - are you walking from workstation to workstation in work? (I don't ridicule the idea just don't understand the reason - maybe you do have some expensive software tied to a workstation, used by multiple users?)I do use the tools for private code or private machines. I do use the tools for shared machines or for multi-user coding projects. Two examples for me: a) I can work on an FPGA project both at work and at home (which I did after the baby was born). b) I do most of my development at my workstation, but we have test stations that need access to the projects, too. Also, I did a rather large LabView project (in the repo, too!), mostly at my desk, and I'd go to the test station and check out the project, build it, run it, test it, etc. In either case, there was never a doubt that I was working on the most recent versions of the project. Just do an svn update and you've got the new stuff. Also, SCC tools allow you to create test branches. For example, say you want to spin off a piece of code that you will modify in some way for testing, but you still want to maintain a pristine copy of the working code (the trunk). The test code will evolve, but you can always go back to your original version without worrying that you broke it. The most attractive thing I was promised when started CVS/SVN (and being preached extensively about its positiva ONLY), was support for multiple users working at the same project. I found that the realisation of this is falling very, very short of my expectations. I found it to be very hard to find out, what has been changed by whom, when, how, and why; Um, at least for subversion, you have svn log (which shows the commit logs) and svn blame (which shows who modified what, when). and also found no tools to enforce some sort of common working culture. I know there are more extensive "collaboration" tools which might fulfill these expectations - I don't know. Maybe we just did not use it in the right way - I don't know. If you can go into more details in how do you use SVN for helping multiple users developing the same set of sources, I would be grateful. No piece of software can truly replace COMMUNICATION BETWEEN THE ENGINEERS. Now, having said that: Say, for example, I check out project and work on it. So do you. I commit changes and now your working copy is out of date, and when you go to commit, if my changes overlap yours, then you get a "conflict" which must be resolved before your changes can be committed. Subversion will tell you the differences between the trunk (what's in the repo), the changes I made, and your changes, and then you and I can work out the true differences and then you can complete the commit. Now if you are working only on file X and I changed file Y, then when you commit, there are no conflicts and the commit goes smoothly. A typical working day is as follows. If you are starting work on a project you haven't worked on before, then you check it out of the repo. If you already have a working copy, then you do an svn update to get the latest changes others may have made. (You might also wish to do an svn log to see what those changes might be.) Then as you work, commit "good" changes, IOW, things that are tested and will build, so when your colleague updates, your changes won't break his working copy. Some development teams like to use "private branches." This means that I have my own branch of the code, and you have yours, and my changes are committed to my branch only, and your changes go to your branch. At regular intervals (daily, whatever) you talk to each other and merge all of the private branches back to the development trunk. There is no enforcement for annotation, i.e. it has the same value as a simple changelog - both need a self-discipline to keep them useful. And, the history features are in fact compare tools, which do exist outside CVS/SVN (if I recall correctly, in fact, they ARE standalone tools used by CVS/SVN). Again, if I am terribly wrong, please, tell, in which way is this more safe/easy-to-use etc. than just simply zipping up the sources and putting them aside. A proper version-control system zips up the sources and puts them safely in a repository where you can get ANY version that you desire. You don't have to create a scheme that organizes that stuff for you. You don't have to find the right zip file, unarchive it to some temporary area and diff it with a different version -- you just do the diff directly on the repository. -a |
