Oof. Keep lines to 80 columns or less, please.
On Wed, 2002-10-09 at 10:58, Brad Appleton wrote:
> * 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?
You would use the last-changed-revision of the file, which is easy to
determine from local working directory state. (svn status -v gives it.)
Why does your build system look at the rev-id of files? The file might
change without the rev-id changing (local mod), and the rev-id might
change without the file changing. If you're too paranoid to trust the
mod time, a checksum seems like a better choice. (A changed rev-id
might make a good heuristic that you have to recheck the checksum, but
it's not a very good final indicator.)
> * if a clone is "diffy", then when I do an "update" to my workspace,
> does that create a new version of my clone branch?
I can't quite understand this question. The clone being "diffy" is
purely a performance issue, though; if you "svn copy dir1 dir2", dir2
does not automatically change when dir1 changes.
> * 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?
This question is also difficult to understand. Strictly speaking, you
can't commit a file which has had parallel/concurrent activity. You
have to merge in the changes. (If you mean that a copy of the file had
parallel/concurrent activity, then that makes very little difference to
the archive format.) Regardless, we never record new information for
files or directories which have not changed during a commit.
> 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 :)
I don't know if you can get exactly the behavior you want from
Subversion. Basically, Bitkeeper is exposing information about files
which isn't really there in a whole-tree model. You're using this
information as a heuristic to determine when files have changed. We do
have information which could be used for this purpose (the node-revision
ID of files, or the checksum of the base text), but we don't expose it
to the user.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 9 18:28:21 2002