Frank Graf wrote:
> Am 24.08.2004 um 2:11 Uhr schrieb Max Bowsher:
>> In CVS $Log$ was implemented as a messy kludge. Two of the most severe
>> resulting bugs are:
>>
>> * Lots of merge conflicts
>>
>> * If you change a log message, the value in $Log$ doesn't always get
>> updated.
>>
>> Implementing $Log$ right has a lot of potential pitfalls:
>>
>> * What if the log contains "$"? Or even worse, other keywords?
>
> Okay, I see technical problems involved with this and that a developer
> can get the same information by using the command svn log, without
> causing all this problems.
>>
>> * Do we really want to traverse the entire history for every file we
>> checkout?
>>
> No but CVS found a way, for which they needed only the last commit
> message.
> Okay, the way $Log$ has been expanded was different than the way used
> for other key words and you have now guarantee that it is hundert
> percent correct. But on the other side you had the freedom to change
> it.
This very 'freedom' is what I (and I suspect others too) consider to be one
of $Log$'s most horrible bugs.
>> And also, there is doubt that $Log$ is the right solution:
>>
>> * Since revisions generally apply to groups of files, wouldn't a
>> seperate logfile be better (assuming that for some reason you can't
>> run "svn log" as needed).
>
> But from the users perspective I still think it is very beneficial to
> have the history, which lead to this particular file directly
> available. So there is no extra action the user had to perform to get
> the information. And this information is available even if the source
> control system is not available.
>
> It is true that revision generally apply to groups of files. But in
> case you are reviewing a certain source file, your starting point is
> from this particular file. You want to list all the commit messages
> which led to this version of the file.
>
> From my experience, having developers to maintain a separate log file
> by hand or even an log history as a comment in the file, will not work.
> It is sad, but it is this way.
I was really suggesting that people use "svn log" as needed most of the
time, and simply do "svn log > somefile" if they are preparing for a period
of disconnected working.
>> If you discuss why you currently use $Log$, perhaps we can suggest an
>> alternative.
>
> So what I was looking is an automatic way to include the revision
> history into the file without having the developers to do anything.
> I hold the $Log$ mechanism of CVS for a goog practical compromise
> between automatically getting the information and having the freedom to
> modify this information.
More than anything, this is a conflict of philosophies. The general idea
common around the subversion project is that putting log data in files is a
flawed solution - because it duplicates log data across multiple file
whenever there is a multi-file commit, because it places a large block of
extra text which must be often scrolled past into the text, and because
people then seem to think they can modify the expanded value of the keyword
for some reason.
Subversion cannot do exactly what you want it to. Perhaps your working
practices can adapt to a way of viewing logs which does have these flaws.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
AdmID:B84ACB29B99E3B5EFC394CA788A9749D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
- application/octet-stream attachment: Mime.822
Received on Tue Aug 24 14:08:30 2004