Re: Adding changeset-like functionality to subversion

On Tue, Oct 08, 2002 at 03:11:35PM -0500, Ben Collins-Sussman wrote:
> http://subversion.tigris.org/files/documents/15/17/svn-design.html#Repository%20Structure

Thanks - that was helpful! I have some questions now about the
cloning and repo-wide revision numbers.

* so if a particular file does not have its contents change between two subsequent versions of the repository, it seems it still has a different version number for that file (yes?)

If so, how do I use svn with more sophisticated build tools like Odin or Cons (which look at not only last-mod times of files, but also their rev-ids and their build command-lines) so that it knows NOT to recompile a particular file if it hasn't "changed" after I updated my workspace? If the file contents didn't change, but the file revnumber did change, what do I tell Cons to use (instead of the rev-id) so it knows not to recompile? (whatever it does, I t should take no more time to do than determine the rev-id, otherwise it impedes my build-time for all builds)

* if a clone is "diffy", then when I do an "update" to my workspace, does that create a new version of my clone branch?

* if I "commit" my changes, and if some of the files I changed did have parellel/concurrent activity, but some didn't, does the archive format record a new branch for ALL the files in my change-set, or just the changed-files?

I'm trying to avoid the kind of "copymerging" from branch-to-branch that I typically have to do in ClearCase and Perforce. When I "commit" my changes back to the main codeline, I still have to create a branch-in-advance for my entire change-set. If I was the only one that checked-out some subset of those files between checkout-time and commit-time, those files are still on my branch and still require trivial copymerging from my branch back to the main codeline. This causes two issues for me:
 - All those copymerges can add up to a lot of additional time if I have a lot of files in my system and a lot them didn't have any parallel development at the time.
 - It makes it harder to see in an annotated listing, which "changeset" truly introduced the changes (as opposed to merely propagated them).
It also is another case of when I have to have two different rev-ids on two different branches refer to the same contents of the same subset of files (and hence can affect my build times very drastically).

If the kind of "local copy" described in the design notes were implemented, then at global "commit-time" svn could figure out which files in my change-set did have parallel activity upon the branch I'm merging them back to, and which ones didn't, and only "branch" the files (and create new revnumbers for the files) that had genuine parallel activity. (This is one well-advertised feature of BitKeeper that makes it very appealing :)

-- 
Brad Appleton <brad_at_bradapp.net>  http://www.bradapp.net/
 "Education is the ability to listen to almost anything
  without losing your temper or your self-confidence."
   -- Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org