Feature idea: Hierarchal logs (views? subrevisions?)

Hello,

Hrm. This E-Mail got pretty darned confusing. I suggest you scroll down
to "My Initial E-Mail" below (look for -------) and read that stuff.
Then jump back here and read on...

Okay. So just when I was about to send this E-Mail I realized that what
I am proposing is much more difficult than I thought. For starters, logs
are per revision, there is nothing indicating that a certain log message
pertained to a certain part of the tree (other than making educated
guesses based on what got modified).

Then, I realized the whole thing just doesn't make much sense at all
because there isn't really a way to fundamentally quantify exactly what
constitutes the changes being merged, as the diffs (mental or otherwise)
between trunk and experimental may look a lot different than the
original diffs in experimental.

But, I'll send the stuff I wrote anyway. Perhaps I'm missing something.
Is there a good way to manage situations like these?

It would be particularly useful to *somehow* do something like this in
cases where you want to create your own little branch for playing around
with new features under version control but without officially
committing them to the trunk (sort of a "scratch" feature that I think
Aegies implements). I actually has a situation like this not long ago
with a group of 5 people using CVS. We went for a completely different
(not as good) solution in the end.

Hmm. I think I just realized what it really is that I am looking for. I
want to be able to commit *a set of changes*. That is, I want to be able
to create a set of logical commits/diffs in the repository separately
from the main tree. I want to be able to work against this "scratch"
version of the repository. Sort of like views for tables in relational
databases, except in this case it's a view of the repository.

When I'm done, I don't just want to commit my current code like normal.
I want to commit my view. I.e., I want to logically "commit the
commits".

Imagine something like:

   ... working in a checked out directory ...
   svn changeview experimental
   ... do variouis stuff, commit changes, etc:
   svn commit -m '* Did something'
   svn commit -m '* Did something else'
   ... decide to commit to the main view:
   svn changeview main
   svn commitview experimental

I suppose it could also be considered transactions in the relational DB
sense. I.e., you start a transaction (or int his case possibly "attach"
to an existing transaction), make variouis changes and then commit the
whole thing as one logical unit.

The result of an "svn log" after the above should show each individual
"sub-revision" with "did something" and "did something else".

Am I making sense?

------------------
My initial E-Mail:
------------------
I have an idea w.r.t. the handling of logs (i.e. commit comments). It
may have been discussed before; haven't been on the list for that long.

The issue concerns branching. It is farily common to want to develop
in one branch and then merge it back into the head branch on occasion.
There is one problem with this; it makes changes more difficult to
track[1]. Why? Because when merging changes from a branch you provide a
log message for the merge, as a unit. You loose the messages logged
when the changes to the branch being merged was done.

What I am proposing is a way for a log entry to have "sub entries". For
example, suppose I'm working in /branches/experimental:

   ...
   svn commit -m '* Re-wrote internal thing-a-magig'
   ...
   svn commit -m '* Fixed deadlock bug in transaction handling.'

After having tested the changes, I merge it back into the trunk
with -m '* Merged experimental branch with trunk.'.

A couple of months later, I inspect the log of the revisions in the
trunk. I no longer remember *which* changes got merged.

So what if there was a way to "expand" the log message for the merge so
that I could instantly see exactly which changes from experimental got
merged?

[1] With a manually maintained ChangeLog it does not get all *that*
hairy, but still.

-- 
/ Peter Schuller, InfiDyne Technologies HB
PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller@infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller_at_infidyne.com Web: http://www.scode.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org