On Tue, Nov 18, 2008 at 4:52 PM, joseph [EMAIL PROTECTED] wrote:
1) why does Versions create 3 extra versions of the file if there is a
conflict? They kind of get in the way as I always have to modify the
main file and dont look at the .mine, .r19, .r20 ? Can it not just say
conflict, here's a fileMerge window for you to create a single file
from these two ?
If you know which version you want to use, then you can just throw out the
file and replace it with one of the 3 versions, which are:
Your modified file (.mine)
The BASE of your modified file (.r19, i.e., the version you began editing)
The updated version of BASE, excluding your changes (.r20 -- the other
developer made changes to .r19 and committed, creating .r20).
Usually, I just go through the un-extensioned file and resolve the
conflicts, but sometimes this isn't possible and you just need to throw it
out and use one of those versions (like with images / other binary files).
2) every time I 'update' do I need to check the log for which files
have been updated and compare changes with files I have modified? I
don't see when you would use the 'diff' command, apart from times
where there has been a specific conflict that Versions notifies of.
You should just so you know what's going on and pre-empt problems. If there
is a conflict where it's not clear how the changes should be merged, svn
will let you know, but there's the other kind of conflict where someone
changed the file in a way that breaks functionality.
3) If myself and my colleague update and commit regularly as we work
on the same project throughout the day and never see a 'conflict'
error from Versions, can we assume that at the end of the day our work
has been merged in both the repository and our working copies without
issue?
Yes. Except for issues where your changes conflict in a functional way with
theirs (like I said above).
On Tue, Nov 18, 2008 at 4:57 PM, joseph [EMAIL PROTECTED] wrote:
Forgot one thing - is it generally good practice to commit one file at
a time with a comment for each?
(obviously there may be exceptions where a group of files should be
added at the same time)
It's up to you -- if a functional change takes place across many files, like
adding an image into an html file, then you could include both files in the
commit (M index.html, A image.jpg). Or, if a bug requires you to rework
many files, then you can commit all of the files at once with the message
Fixed X bug. It's kind of subjective what a revision is. Best to just
try out what works for you.
Keep in mind that if you want to revert a single change, you will be
reverse merging by revision numbers. It's easier if each revision is a
logical change and doesn't combine many changes in one commit that you'll
have to sort through after merging.
Ray
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Versions group.
To post to this group, send email to versions@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/versions?hl=en
-~--~~~~--~~--~--~---
