Re: svn commit: rev 4988 - in trunk: . notes

On Friday, February 21, 2003, at 01:25 PM, Karl Fogel wrote:

>> ii) Branching is only somewhat useful at the moment as merging is
>> poor. In particular, the software they are developing has been
>> undergoing major code re-arrangements (the current group of undergrads
>> inherited it from the previous group, and the handover process seems
>> to involve lots of renaming... sigh). This breaks merging. Alot of
>> the merging has been done manually.
>
> It seems like we could use their bug reports, then.

I've been filing some, and some are already filed. (e.g. Issue #1141 is
a biggie, as is Issue #898) Here is an example of 1141 in action as it
relates to updating after a rename: (fixing either of 1141 or 898
would make this less of a problem - 1141 fixes the delete part of the
current rename=copy+move implementation, 898 changes rename so it no
longer involves delete.)

% svnadmin create repos
% svn co file://`pwd`/repos wc
Checked out revision 0.
% cd wc
% echo "hello" > file
% svn add file
A file
% svn commit -m "added file"
Adding file
Transmitting file data .
Committed revision 1.
% cd ..
% svn co file://`pwd`/repos wc2
A wc2/file
Checked out revision 1.
% cd wc2
% svn mv file newFile
A newFile
D file
% svn commit -m "moved file"
Deleting file
Adding newFile

Committed revision 2.
% cd ..
% cd wc
% echo "Hello again" >> file
% svn commit -m "this should fail as I'm not up to date"
Sending file
subversion/libsvn_client/commit.c:670: (apr_err=160013)
svn: Filesystem has no item
svn: Commit failed (details follow):
subversion/libsvn_fs/tree.c:180: (apr_err=160013)
svn: file not found: transaction `3', path `file'
% svn up
A newFile
D file
Updated to revision 2.
% svn commit -m "Whoops - my changes are not going to be committed here"
% ls
file newFile
% svn st
? file
% cd ../wc2
% svn up
At revision 2.

Note that the latest set of changes to wc is silently not committed.
If you assumed that your commit had worked and removed your working
copy, you'd lose the changes.

>> iii) The students take a while to pick up on the concept of a
>> working copy and .svn directories. They like to copy bits of working
>> copy around between users/machines. This doesn't work well... :)
>
> Is it worse than CVS in this respect? Is there some way they can copy
> bits of working copy around in CVS that they can't in Subversion?

I'm not sure it is worse than CVS, except that there is more in the
.svn directories for them to screw up. I'll be updating to 0.18 this
weekend. I'll be very happy for the checksums...

Part of the problem with subversion is that they have understand the
difference between 'cp' and 'svn cp'. When you're copying bits of
working copy around you have to have this very clearly in mind. CVS
doesn't have this problem :).

later,

Will :-}

--
Dr William Uther                            National ICT Australia
Phone: +61 2 9385 6926             School of Computer Science and 
Engineering
Email: willu@cse.unsw.edu.au             University of New South Wales
Jabber: willu@jabber.cse.unsw.edu.au          Sydney, Australia
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org