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

RE: Pre-commit transaction modification question

From: Jan Evert van Grootheest <j.grootheest_at_euronext.nl>
Date: 2004-02-12 09:59:42 CET

Hmm, regarding Bretts suggestion to send a checksum with update, I think it
is a good idea. SVN should err on the defensive side.

For the following simple reason:
No matter what state my working copy is in, svn update absolutely has to
make sure that its output is accurate.

For me this means:
If it says that my file is up to date, then it can only mean that the base
version in the .svn directory is equal to the same version in the
respository and the file I work on is equal to the base version in the .svn
It should detect that base versions got corrupted (no matter the reason).
Drives corrupt, chips fail and bits flip randomly.

Personally, I feel that in the update case it must be defensive: get the
checksums for each file in the WC and check those against the base versions
that are in the .svn directories. Only then accurate output can be

-- Jan Evert

PS: the same is true for cleanup, obviously, as the combination of cleanup
and update should be able to get a working copy back in order.

> -----Original Message-----
> From: Brett Wooldridge [SMTP:brettw@riseup.com]
> Sent: Thursday, February 12, 2004 2:49 AM
> To: simon@ecnetwork.co.nz
> Cc: users@subversion.tigris.org
> Subject: Re: Pre-commit transaction modification question
> Simon Kitching wrote:
> >On Thu, 2004-02-12 at 12:57, Ben Collins-Sussman wrote:
> >
> >
> >>On Wed, 2004-02-11 at 17:48, Brett Wooldridge wrote:
> >>
> >>
> >>
> >>>CVS has the same 'issue', in that after checking in the source, the
> >>>source in the repository nolonger matches the source on the user's
> >>>system [...] the only side-effect being that an immediate diff will
> >>>show the differences in formatting, but after an 'update', the work is
> >>>right again.
> >>>
> >>>
> >>That won't work in Subversion. Honest. 'svn diff' is not a network
> >>operation: it compares the working file with the cached copy in .svn/.
> >>
> >>It's worse than that: when you run 'svn up', the client says: "I have
> >>version N of foo.c".
> >>
> >>
> >
> >Just in theory, the client could say "I have version N of foo.c, with
> >checksum xxxxx". The server is then able to detect this and return a
> >corrected file. The .svn/Entries file already holds a checksum for each
> >base file, doesn't it?
> >
> >Not that I'm asking for a new feature - just pondering.
> >
> >
> I have to agree with you. The checksum (or MD5 hash) method was going
> to be my
> suggested solution. Additionally, it seems like running a 'diff' off of
> a local cached copy
> is possibly frought with issues of it's own. What if the file has
> changed dramatically on
> the server through another commit? My diff isn't going to show that?
> Anyway, regardless of the diff issue, it seems like update could
> certainly send an MD5 hash
> along with the version. In fact, I'll be glad to implement it, if it
> would be welcome.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

 === E U R O N E X T - D I S C L A I M E R =============================

 This e-mail and its attachments are only intended for the individual(s) or
entity(entities) named above to whom they are addressed and may contain
personal and/or confidential information. Please notify us immediately if
you are not the intended recipient. Any dissemination, duplication,
publication to third parties or other use of the contents of this e-mail or
its attachments is forbidden. Although this information has been compiled
with great care, neither Euronext N.V. nor its subsidiaries shall accept any
responsibility for any errors, omissions or other inaccuracies in this
information or for the consequences thereof, nor shall it be bound in any
way by the contents of this e-mail or its attachments. In the event of
incomplete or incorrect transmission please return the e-mail to the sender.

 Cet e-mail et ses annexes sont uniquement destinés à la (aux) personne(s),
ou à l' (aux) entité(s) à laquelle (auxquelle(s)) il est adressé, visée (s)
en tête du présent message. Il peut contenir des informations personnelles
ou confidentielles. Merci de nous notifier immédiatement si cet e-mail vous
a été adressé par erreur. Toute diffusion, copie, publication à des tiers ou
toute autre utilisation de son contenu est interdite. Bien que cette
information ait été rassemblée avec une grande attention, ni Euronext N.V.
ni aucune de ses filiales, ne peut être tenue responsable des erreurs,
omissions ou inexactitudes contenues dans cette information, ni ne peut être
liée d'aucune manière par le contenu de cet e-mail ou ses annexes. En cas de
transmission incorrecte ou incomplète, nous vous prions de retourner cet
e-mail à son émetteur.

 Deze e-mail en zijn bijlagen zijn uitsluitend bestemd voor de
geadresseerde(n) als op dit e-mailblad vermeld. Het is mogelijk dat deze
e-mail persoonlijke en/of vertrouwelijke informatie bevat. Wanneer u niet de
geadresseerde bent, verzoeken wij u dringend ons daarvan te berichten. Elke
verspreiding, vermenigvuldiging, gebruik of openbaarmaking aan derden van de
inhoud van deze e-mail en zijn bijlagen, is verboden. Hoewel deze informatie
met de meeste zorg is samengesteld is Euronext N.V., en de tot Euronext N.V.
behorende werkmaatschappijen, op geen enkele wijze aansprakelijk voor
eventuele fouten, omissies of andere onjuistheden in deze informatie of de
gevolgen daarvan noch op enigerlei wijze gebonden aan de inhoud van de
e-mail of zijn bijlagen. Gelieve, in geval van onjuiste of onvolledige
ontvangst, deze e-mail terug te sturen naar de afzender.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 12 10:01:31 2004

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

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