(Amendments at the request of Julian Foad)
My expectations of the logical working of this feature are:
Import and checkin:
Configuration:
Global:
- Option to store the modified datetime for all files. On =
stores datetimes.
Default: on (See requirements 3)
Per file:
- The ability to set a flag to say to store the modification
datetime.
Default: Not set
Change Checking:
- The modification datetime will not be used to determine is a file
has changed. This will be done using a binary compare (as is currently
the case)
Storage:
- The modified timestamp for the file will be stored for every
revision of a file. i.e. if it is set ten the modified datetime will be
stored whenever a file delta is stored. And if it is not set then the
global flag behaviour is used. (It would not be a good idea to remove
the modification datetime from the checkins that had this flag set as if
this is accidentally set then you will have permanently lost information
from the repository and thus if you reverted to revision 1234 you would
not get the same results as before the flag was removed and readded.)
Export and checkout:
Configuration:
- 4 options available to the client for the setting of the
modification datetime:
1) Use the current datetime
2) Use the checkin datetime
3) Use the original file datetime. If this was not stored in the
repository then the current time should be used (this can then be used
by the user to know that there was no modification datetime available)
4) Use the original datetime for all files that have the per file
storage flag set. To allow for the people who want the docs with their
original modification datetime but the source with the current datetime.
(This differs from 3 in that if the global store datetime flag is on
then this will give the client the ability to get the behaviour as if
the global store datetime flag was off when a file was checked in. i.e.
for developers that want to use the current datetime for source files
that are stored on a server that is storing the modified datetime for
all files.)
Summary:
I believe that this covers all of the various use cases for this feature
which are:
1) Using it on specific non source files, but keeping compatibility with
make for source files.
2) Using it for every file for compatibility with company procedures
that use the modified datetime to specify a file.
3) Not using it at all.
Requirements:
1) Maintain compatibility with the existing system.
2) Do not change the default behaviour of the system as there are a lot
of people out there that have expectations of the system.
3) Enable the novice to set up the system and to then have this option
available in the future. It would be highly frustrating to have worked
on a system and then want to get the modified datetimes only to find out
that you did not set an option that you didn't know that you had to.
Advanced users that do not want this feature can turn it off to save
storage space and processing time.
4) Allow the client to choose how they want to get their files out.
I hope that this is clear, I feel that this is an issue where subversion
should simply provide the functionality to satisfy these use cases and
would thus allow for people who want to work in whatever way that they
want and for their own reasons. I personally see the benefits of working
with the current time for compatibility with make, but at the same time
I prefer to work with the original modification datetimes and then use
make -B whenever I do an update. It may take a little longer but it
gives the same safe end result. This modification will enable everyone
to work the way that they are happiest.
Thanks,
Graeme
******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 28 18:01:54 2005