|
Subversion model
We are using Subversion mainly because Perforce is way to expensive for us -- 3 developer ISV.
I can't get use to the Subversion model of not locking files (booking out) as in Perforce. Any comments on subversion vs perforce iro the model used?
------------------------------------
We are using it mainly to control VB6 code + other docs.
I am very happy otherwise with Subversion .. just the fact that it doesn't lock files ...... or am I missing something
Liam
Tuesday, May 4, 2004
The subversion book http://svnbook.red-bean.com/ has a pretty good explanation of the lock-unlock model versus the copy-edit-merge model of source control. Each one has advantages and drawbacks.
Copy-edit-merge is more useful when you have more people working on the source tree. It also makes things easier to manage on the server side because you don't have to track checked out copies. I can check out a copy of the source, mess around with it, and delete it, all without interfering with someone else's work. If I do try to commit changes, those changes will be merged with any other changes that are happening to the source.
Lock-Unlock is easier to follow logically. It also works better with binary files. After all, you probably won't be merging binary data, so exclusive checkouts are better.
Most of the higher-end source control systems will support both. Subversion doesn't yet, but it is planned.
Myron A. Semack
Tuesday, May 4, 2004
Myron -- yes I saw the models in the Subversion book but wasm't convinced at the time.
I'll stick to Subversion -- very good system & I can't wait for the locking option to come in.
Liam
Tuesday, May 4, 2004
Crazy coincidence. I was going to post on this very topic. Subversion makes it look like everyone is supposed to be editing everything, which will send the wrong message to less-experienced developers. If multiple people are regularly editing the same file, your code isn't modular enough.
When will the Lock / Unlock option be available, anybody know the ETA?
Jonathan Boutelle
Tuesday, May 4, 2004
The relevant feature request:
http://subversion.tigris.org/issues/show_bug.cgi?id=533
It seems like this is against the "subversion world view", but IS percieved as a must-have feature by the market. Excerpts below:
"While the early adopters may believe that Locking is Evil, the stragglers are more likely to believe that Locking is Safe and Good Management Practice. It is easier to change
the technology to suit the people than to change the people to suit the technology... The situation is of several developers in adjacent workstations who are all working for the same manager in a large corporate. This means that issues of governance can be settled directly by the responsible manager."
Jonathan Boutelle
Tuesday, May 4, 2004
The subversion model works fine. I just wish you had to explicitly open a file for edit like perforce. A lot of times I make local edits to files that I don't want to check into the repository (say configuration files). I always forget that I modified them, and hence they end up getting checked in the next time I submit my changes.
christopher baus (www.baus.net)
Tuesday, May 4, 2004
Try exporting a copy instead of checking it out.
Myron A. Semack
Tuesday, May 4, 2004
I've found that I really wish it had locking checkouts for binary files.
I use Subversion for source code, and it works really well.
However, my counterparts in Hardware Engineering are also using it for checking it board schematics, PCB layouts, CAD component libraries, and Gerber files. These files are all binary formats, so multiple people checking it out does more harm than good. We had one incident where one of the CADers forgot to update his working copy after another CADer did some work. Since there's no way to merge the changes, we lost a few hours of board layout.
On the bright side, it works wonders for our VHDL and Verilog designs :-)
Myron A. Semack
Tuesday, May 4, 2004
Myron,
I'm having trouble resolving your last two posts. How does exporting a copy of the repository solve the problem, and if so, why doesn't it solve the problem for binary files?
Thanks,
Jon
Jonathan Boutelle
Tuesday, May 4, 2004
christopher -- my point exactly.
Also, what I don't get with Subversion is how do I know someone else isn't working on the same file at the same time. I don't want to find it out when trying to "Update" the repository -- it is a few hours to late. If I know someone else is working on the file I would have done something else (or communicate to them that I need to do the work).
It is all well suggesting (in the manual) that team members need to communicate what they do but Subversion should be the medium. How else should people communicate this info?
With Perforce one can see it easy because one can see who has booked out what -- On my wishlist for Subversion is that all files are "read only" by default. Users must then change the status ("book out") but possibly allow more than 1 user to "book it out".... (this might be a server option). If more than 1 user can book it out -- multiple people can work on it -- at least they know about it.
Anyway .. I get the idea there are a few people that feels the same (I don't see any Perforce users complaining about the fact that files are locked).
Our small team is scatted accross the globe ... our version control software must assist us with communication not just store documents.
Thanks
Liam
Liam
Wednesday, May 5, 2004
Jonathan: if it works like CVS, exporting is grabbing files from the repository without being able to check them back in. You do this if you want to give customers your source code or test out some new feature without accidentally checking it back into the repository.
Liam: if your team is scattered around the globe then how likely is it that they'll be working on the same files at the same time? (not sarcasm)
Chris Winters
Wednesday, May 5, 2004
Good morning all,
I'm working on converting my company over from VSS to subversion. I've found out about a perl script that checks out each individual file and checks it back in....
Does anyone either have that file OR have a better solution?
Thanks.
KC
Wednesday, May 5, 2004
Exporting lets you pull a copy of the files out of the repository without checking them out. When you export files, no .svn directory is created. Hence, you can't accidentally check it in.
My second post was a rant about why locking can be useful :-)
Myron A. Semack
Wednesday, May 5, 2004
Liam:
When you try to commit files that someone else has updated, Subversion tells you about the conflict. You're then presented with three files, theirs, yours, and the merged file. You merge the changes between the two copies into the merged file and then flag it as resolved. TortoiseMerge does this really well.
The idea is that multiple people are Supposed to be able to work on the same file.
Myron A. Semack
Wednesday, May 5, 2004
Myron, Chris,
Yes, I understand what exporting is. It's just grabbing a copy.
It doesn't solve the central problem at all, which is that multiple people may be working on a file without knowing that others are making the same changes. If you want to make ANY changes to ANY files you'll have to check out the directory, and then you'll be back where you started, checking in changes you didn't want to.
Humans have terrible memory: yet subversion is designed such that it expects the developer to remember all the files that they've changed since the last update, and constantly communicate with your team members to make sure you're not both making similar / incompatible things to the same file.
Systems like perforce, OTOH, allow multiple people to work on the file at the same time and merge changes later, but they still track the editing of files, making you "opt-in" each time and maintaining a list for yourself and others of who is working on which files.
I get the impression that the objections to this model may be political: maybe people doing open source like to feel like the whole source tree is their playground, while corporate programmers are more used to there being more centralized control?
Jonathan Boutelle
Wednesday, May 5, 2004
What I'm suggesting is that if you need to work with a copy of the source tree, and you don't want it to accidentally be checked into the build, you can just export a copy instead of checking one out.
Myron A. Semack
Wednesday, May 5, 2004
KC,
I found the script here.
https://chidb01.tallan.com:4430/vss2svn/
My company also wants to move from VSS to Subversion or CVS but we have not done so yet (unfortunately, it is not an urgent priority).
So, I haven't tested the script so I cannot comment on how well (poorly) it works.
A.F.
Avrom Finkelstein
Wednesday, May 5, 2004
Myron,
Yes, if you just want to play with the code and are not going to be contributing those changes to the source than exporting obviously would be the thing to do (build engineers and people investigating an API they are a client of would fall in that category).
What christopher was complaining about was not this use case (I think). His situation described involved making inadvertant changes in same tree that he makes purposeful changes in (since he is committing the changes later).
Jonathan Boutelle
Wednesday, May 5, 2004
Regarding the lack of a "book" function in subversion (where you declare your intent to make modifications to a file, but don't get an exclusive lock), it's particularly strange that they didn't implement this as the feature exists in CVS (edit/watch) and is pretty popular (at least, all the tools support it).
One reason I like the edit feature is that it works great as a middle ground compromise that will get exclusive-lock-fanatics and copy-merge-fanatics using the same tools.
I poked around and the subversion people do place it in the vague "post 1.0" feature set.
Bill Tomlinson
Wednesday, May 5, 2004
Liam,
You can check the status of the repository vs your local working copy with:
svn status -u
At the top of your working directory. This is a major change over CVS where you had to just do an update to see what changed (too late for you if you have conflicts).
svn status
Just hows you what you have changed locally.
If svn status -u shows that you have modified a file that someone else has updated you can do two things:
svn cat -r HEAD <filename> > out
To get a copy of the file from the repository.
svn diff -r HEAD <filename>
Will just get you the diff from the head to the file.
Probably another way... I've only been using it for a month
or so... And have a little script for launching a diff tool:
TEMPFILE=`tempfile`
svn cat -r HEAD $1 > $TEMPFILE
opendiff $TEMPFILE $1
Dave
Friday, May 28, 2004
 Recent Topics
Fog Creek Home
| 
