Source control and roaming the glens...
-
OK, that means absolutely nothing to me (not in this context anyways). This thread is showing more and more of my ignorance. Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
-
Another point of ignorance exposed. If I can just do a chunky checkout, then merge on return without stepping on too many toes, the problem goes away. I had understood checkout to be more of a locking activity than it apparently is! And emailling back changes could be a handy trick. Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
Iain Clarke wrote:
I had understood checkout to be more of a locking activity than it apparently is!
Yeah, it is a hangover from older source control systems which locked files on checkout and unlocked them on commit. SVN can be setup to work like this and other source control systems still do it (perforce for instance.) It is up to you what you prefer but you'll find most major open source projects use the "copy-modify-merge" model instead of the "lock-modify-unlock" model.
regards, Paul Watson Ireland & South Africa
Fernando A. Gomez F. wrote:
At least he achieved immortality for a few years.
-
Iain Clarke wrote:
I had understood checkout to be more of a locking activity than it apparently is!
Yeah, it is a hangover from older source control systems which locked files on checkout and unlocked them on commit. SVN can be setup to work like this and other source control systems still do it (perforce for instance.) It is up to you what you prefer but you'll find most major open source projects use the "copy-modify-merge" model instead of the "lock-modify-unlock" model.
regards, Paul Watson Ireland & South Africa
Fernando A. Gomez F. wrote:
At least he achieved immortality for a few years.
So, I'm not terribly ignorant, just out of date. Hmm, is that better? Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
-
A question came up at work recently, though I've thought about before. You have a nice shiny source control system, and many happy developers at code headquarters. But you need to take your laptop and go to a customers site in the deep arctic, and internet access there is limited at best, and you can only borrow a pc to check your email. You'll be there for a few weeks, and for nothing better to do, will be writing a feature or two in the software, or may need to tweak it to match immediate customer demands. How would that work with source control? If you checked out the code, would that prevent colleagues from working on it in your absence? Your's knowing-source-control-is-a-Good-Thing-but-has-some-conceptual-hurdles, Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
If your source control supports branches, I would create a branch off your main development branch, and create a local view of that on your laptop. You could either check out all the source files and work on them, or manually keep track of which files you've changed. Then check everything back in to your once you are back, and merge from your branch to your main branch. Generally speaking most source control systems would allow multiple checkouts, although it relies on people being smart enough to be able to merge their changes in correctly
-
A question came up at work recently, though I've thought about before. You have a nice shiny source control system, and many happy developers at code headquarters. But you need to take your laptop and go to a customers site in the deep arctic, and internet access there is limited at best, and you can only borrow a pc to check your email. You'll be there for a few weeks, and for nothing better to do, will be writing a feature or two in the software, or may need to tweak it to match immediate customer demands. How would that work with source control? If you checked out the code, would that prevent colleagues from working on it in your absence? Your's knowing-source-control-is-a-Good-Thing-but-has-some-conceptual-hurdles, Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
Lovely sig :D
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighist -
Lovely sig :D
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
blog: TDD - the Aha! | Linkify!| FoldWithUs! | sighistIt does have a little history behind it... We played a lot of sig tag when I was about more two months ago. Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
-
krmed wrote:
it's a simple matter to merge things back to the mainline code
That statement can only be true for the most degenerate cases, where the components that the separate users are working on are completely separate and have static, well-defined interfaces to other components.
Software Zen:
delete this;Gary Wheeler wrote:
That statement can only be true for the most degenerate cases, where the components that the separate users are working on are completely separate and have static, well-defined interfaces to other components.
Actually, even complex cases can be merged very easily in ClearCase. Perhaps you've not worked with ClearCase and merged such cases. It works extremely well, even if 3 or 4 people have modified the same file on different branches.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
-
A question came up at work recently, though I've thought about before. You have a nice shiny source control system, and many happy developers at code headquarters. But you need to take your laptop and go to a customers site in the deep arctic, and internet access there is limited at best, and you can only borrow a pc to check your email. You'll be there for a few weeks, and for nothing better to do, will be writing a feature or two in the software, or may need to tweak it to match immediate customer demands. How would that work with source control? If you checked out the code, would that prevent colleagues from working on it in your absence? Your's knowing-source-control-is-a-Good-Thing-but-has-some-conceptual-hurdles, Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
You can also consider a distributed SCS[^] if you are not already set on a centralized one.
-
You can also consider a distributed SCS[^] if you are not already set on a centralized one.
One of the earlier posters mentioned Bazaar (bzr), which sounds quite interesting. It doesn't require a server setup, so is easier to experiment with. Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
-
Gary Wheeler wrote:
That statement can only be true for the most degenerate cases, where the components that the separate users are working on are completely separate and have static, well-defined interfaces to other components.
Actually, even complex cases can be merged very easily in ClearCase. Perhaps you've not worked with ClearCase and merged such cases. It works extremely well, even if 3 or 4 people have modified the same file on different branches.
Karl - WK5M PP-ASEL-IA (N43CS) PGP Key: 0xDB02E193 PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193
CC's merge tool only burned me once. I was dealing with a client defined WTFXML format help document. Version N of the application temporarily removed feature A. I branched the help document at that point with the A documentation in the new branch and the main branch having it removed. Version N+1 of the app added feature A back. At that point I went to merge the A branch into the main branch. Because of the xml structure and how rationals diff merge tool parsed XML there were (literally) over three thousand changes identified. Automerge didn't add anything that was in the A branch but not the main one. Manual merge required moving through the changes sequentially with no option to go out of sequence, (although you could tell it to automerge all unresolved changes). The problem changes were around the 1500 point. :omg: :wtf: :omg: :wtf: After sending an SoS to the internal helpdesk ("either my finger will fall off, the mouse button will break, or the mouse will throw itself in front of a cat"), which was forwarded to IBM, the official solution was to replace CCdiff with KDiff for XML files. Aside from a truely hideous color scheme it worked fine that way. :laugh:
Today's lesson is brought to you by the word "niggardly". Remember kids, don't attribute to racism what can be explained by Scandinavian language roots. -- Robert Royall
-
A question came up at work recently, though I've thought about before. You have a nice shiny source control system, and many happy developers at code headquarters. But you need to take your laptop and go to a customers site in the deep arctic, and internet access there is limited at best, and you can only borrow a pc to check your email. You'll be there for a few weeks, and for nothing better to do, will be writing a feature or two in the software, or may need to tweak it to match immediate customer demands. How would that work with source control? If you checked out the code, would that prevent colleagues from working on it in your absence? Your's knowing-source-control-is-a-Good-Thing-but-has-some-conceptual-hurdles, Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
Break out a branch for your disconnected work. Manage the disconnected work with some VCS on your laptop (server-less SVN, git, bzr) and commit it back to the branch when you're back in the office. If your nice shiny VCS is Subversion, then I'd put git[^] on the laptop and use git-svn to create a branch within git that has an equivalent branch in SVN. Do your work disconnected, using git as you would any other VCS, then merge the git branch back into the branch in SVN (again using git-svn). This will (IIUC) preserve all history and commits across the SVN/git divide.
-
Iain Clarke wrote:
more and more of my ignorance.
I guess it is not : I doubt anyone understand what he meant but himself. In this context.
I take it to be a joke of some kind.
Todd Smith
-
A question came up at work recently, though I've thought about before. You have a nice shiny source control system, and many happy developers at code headquarters. But you need to take your laptop and go to a customers site in the deep arctic, and internet access there is limited at best, and you can only borrow a pc to check your email. You'll be there for a few weeks, and for nothing better to do, will be writing a feature or two in the software, or may need to tweak it to match immediate customer demands. How would that work with source control? If you checked out the code, would that prevent colleagues from working on it in your absence? Your's knowing-source-control-is-a-Good-Thing-but-has-some-conceptual-hurdles, Iain.
Plz sir... CPallini CPallini abuz drugz, plz plz help urgent.
http://drnicwilliams.com/2007/11/22/going-offline-without-your-favourite-subversion-repository/[^] There are other solutions as well so you can work completely offline and still reap the benefits of SVN. You do a merge once you get back online.
Todd Smith