Questions related to handling of failures on commit

Let me start with the story and throw in my questions as I go.

We have to branches 'a' and 'b' each created from an almost empty trunk (a
and b are not the names of the branches, but just identifiers for this
example.)

After committing about 400MB and 30000 files to 'a', we wanted to merge
these to 'b'. The merge itself went fine, but when it came to the commit
it failed with the following message:

svn: Commit failed (details follow):
svn: MERGE request failed on '/svn/project/branches/a'
svn: MERGE of '/svn/project/branches/a/software': timed out waiting for
server (https://project.something.collab.net)

The person saw the error and basically just repeated the commit. This
commit failed the same place with the same error (this is not what I'm
concerned about at this point, as timeouts can happen). We basically
stopped at this point and did a co of the complete repository to a clean
work area and found that the merge had completed and all the data was
committed (we did a diff between the branches a and b).

Q1: How come the commit actually worked even though the message said it
failed?

The second commit that failed caused the revision of the repository to go
to the next number, but a diff shows that no changes where made.

Q2: How come that the revision is changed even though no data was changed?

We now did an update in the working area where the merge was done to see
what this might tell us and the result was:

svn: Failed to add directory 'software/NET': object of the same name
already exists

Which seems logical, as the data was committed (the server thinks the data
was successfully committed, while the client thinks it failed). So we did
an info and found that the working copy was at revision 6 (the version
before the merge) while the repository now was at revision 8.

Q3: How come that we can keep on trying to commit changes that are done on
an earlier version than the one in the repository? Should we not be forced
to do an update?

I'm not looking for a solution to any problems at this point, but only for
information on the reason behind this behavior.

Q4: Are we doing something wrong here? Or is this expected behavior?

Thanks,
Mads

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 2 12:00:29 2004