How does a Subversion commit work?

Question

I'd like to know how files are transferred to the server. Does the client first send information about in which folder the file exists?

I also don't know when and where the server says that there is a conflict when trying to commit.

Thanks in advance.

Answer 1

I don't really understand your first question. Why would you care about it anyway?

If it complains for a conflict, this is most probably that in your previous workspace update, there are conflict happening. You may have fixed that in the code but you haven't tell SVN that you have resolved that conflict.

Do an svn status should tell you the place containing conflict to be resolved.

Then you can do an svn resolve to mark those conflict as resolved.

(Similar way if you are using GUI)

---

Update (corresponds to your latest comment for the reason):

The best way is to look into the source code of SVN in fact :) However, as you are building up a new system instead of something that needs SVN compatibility, I believe you only need a workable solution instead of implementing what SVN is doing.

There are two solution I can think of (I believe first one is the way that SVN is doing)

1. Send all the (relative) path AND the revision of changed objects to server. Server can simply check if the related object is having later revision in server, which in turns means the file in client is outdated. If there is no out-date response, client then send the actual content to server.

2. Send the actual file content (of course with the path and revision) to server. Do similar checking as described in 1 and if there is no problem then commit directly.

First approach give better performance by avoiding unnecessary traffics. However there are lots of things you need to properly handle if you are writing such kind of revision control system. e.g. if you take the first approach, how can you avoid data change between the first and second call to server? (SVN is having some kind of transaction object). How to deal with move and rename? etc.

If there is no special reason, why don't simply make use of existing SCM as your backend? Either SVN or Git or Hg should save you a lot of problem dealing with such lots of problem.