[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Adding changeset-like functionality to subversion

From: David Mankin <david_at_ants.com>
Date: 2002-10-09 18:11:52 CEST

On Wednesday, October 9, 2002, at 07:58 AM, Brad Appleton wrote:

> 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)
>
>

AFAIK, Subversion keeps an md5 checksum of each file in the entries
file just as it keeps a rev-id. So it would be just as quick (if not
simple yet without such an interface defined) to pull out the checksum
and see if it's changed as to pull out the rev-id and see if it's
changed. Does that satisfy your needs here?

[I don't understand the rest of your email, so I'll leave it to experts
to answer.]

-David

---------------------------------------------------------------------
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:12:51 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.