You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2002/07/25 01:02:47 UTC

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Peter Schuller <pe...@infidyne.com> writes:

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

What you are describing is exactly what the "branch" concept means.

> 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

In Subversion-speak, this would be:

   svn copy -m 'make experimental branch' \
                          http//.../trunk http://.../branches/experimental
   ... remember the revision number we just created here as REV ...
   svn switch http://.../branches/experimental
   ... do various stuff, commit changes, etc:
   svn commit -m '* Did something'
   svn commit -m '* Did something else'
   ... decide to commit to the main view:
   svn switch http://.../trunk
   svn merge -r REV:HEAD http://.../branches/experimental
   svn commit -m '* Merging in experimental changes'

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

Sure.  In the case above :
  `svn log http://.../trunk' - show changes to the trunk only (including merge)
  `svn log http://.../branches/experimental' - show experimental changes.
  `svn log http://.../ - show all changes.

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

I do:

   svn log --strict http://.../branches/experimental | grep -e 'Rev: '

which shows me all the revisions committed to the branch.  When I
commit my merge, I simply note those revision numbers (except the
oldest one, which was where the branch was created) in the log
message.  Granted, that is a policy thing, not something Subversion
does for me.  But we day plan to have Subversion remember this sort of
thing for you later.

Note that you can always `svn rm http://.../branches/experimental'
without losing any data after your merge/commit.  That way you can
re-use the /experimental branch name later and wah-lah, you have a
clean view of the trunk at whatever revision you so desire.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by Peter Schuller <pe...@infidyne.com>.
> What you are describing is exactly what the "branch" concept means.

Hmmm. I'll have a look at the examples you gave tomorrow. It's 03:26
over here so I'm going to sleep. But I'm still not convinced it does
what I want. I'll reserve judgement until having played around with it
though.

Thanks.

-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <pe...@infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@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

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by Tim Moloney <mo...@mrsl.com>.
cmpilato@collab.net wrote:
> Tim Moloney <mo...@mrsl.com> writes:
> 
>>>   svn merge -r REV:HEAD http://.../branches/experimental
>>
>>This is where I get lost.  The above command is the same as
>>
>>   svn merge http://.../branches/experimental@REV \
>>             http://.../branches/experimental@HEAD .
>>
>>which means merge the diffs of the entire experimental branch
>>into the working copy.  Why is this command necessary.  Aren't
>>these changes already in the working copy?
> 
> 
> if they exist as local mods, then yes they are.  if, however, they
> were committed to the branch, then when switching back to the "trunk
> view" they will be removed again (since they don't exist on the trunk).

Doh!  I was only thinking of adding the changes from the trunk.
It didn't even occur to me that the experimental changes would
be removed from the working copy.

> you were this || close!  not bad, i'd say! :-)

A small, but vital, bit of understanding.

Thanks.  =)

-- 
Tim Moloney
ManTech Real-time Systems Laboratory
2015 Cattlemen Road                             \     /
Sarasota, FL  34232                     .________\(O)/________.
(941) 377-6775 x208                        '  '  O(.)O  '  '


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by cm...@collab.net.
Tim Moloney <mo...@mrsl.com> writes:

> Please help me get my brain around this and dumb it down a few
> more levels.
> 
> cmpilato@collab.net wrote:
> 
> > In Subversion-speak, this would be:
> > 
> >    svn copy -m 'make experimental branch' \
> >                           http//.../trunk http://.../branches/experimental
>  >    ... remember the revision number we just created here as REV ...
> 
> A cheap copy was made directly in the repository so at revision
> REV, both .../trunk and .../branches/experimental point to the
> same stuff.

check.

> >    svn switch http://.../branches/experimental
> 
> This switches the base of the working copy from .../trunk to
> .../branches/experimental and applies any differences (which
> there aren't any).

check.

> >    ... do various stuff, commit changes, etc:
> >    svn commit -m '* Did something'
> >    svn commit -m '* Did something else'
> >    ... decide to commit to the main view:
> 
> Commit changes into .../branches/experimental.

check

> >    svn switch http://.../trunk
> 
> This switches the base of the working copy back to .../trunk
> and applies the differences between .../branches/experimental
> and .../trunk to the working copy (if there are any differences).

check.

> >    svn merge -r REV:HEAD http://.../branches/experimental
> 
> This is where I get lost.  The above command is the same as
> 
>    svn merge http://.../branches/experimental@REV \
>              http://.../branches/experimental@HEAD .
> 
> which means merge the diffs of the entire experimental branch
> into the working copy.  Why is this command necessary.  Aren't
> these changes already in the working copy?

if they exist as local mods, then yes they are.  if, however, they
were committed to the branch, then when switching back to the "trunk
view" they will be removed again (since they don't exist on the trunk).

> >    svn commit -m '* Merging in experimental changes'
> 
> Commit the combined trunk and experimental branches back to
> .../trunk.
> 
> I must have some misunderstanding of the merge command (and
> perhaps switch also).  I've reread the pertinent sections of
> the new handbook but it doesn't seem to help.

you were this || close!  not bad, i'd say! :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by Tim Moloney <mo...@mrsl.com>.
Please help me get my brain around this and dumb it down a few
more levels.

cmpilato@collab.net wrote:

> In Subversion-speak, this would be:
> 
>    svn copy -m 'make experimental branch' \
>                           http//.../trunk http://.../branches/experimental
 >    ... remember the revision number we just created here as REV ...

A cheap copy was made directly in the repository so at revision
REV, both .../trunk and .../branches/experimental point to the
same stuff.

>    svn switch http://.../branches/experimental

This switches the base of the working copy from .../trunk to
.../branches/experimental and applies any differences (which
there aren't any).

>    ... do various stuff, commit changes, etc:
>    svn commit -m '* Did something'
>    svn commit -m '* Did something else'
>    ... decide to commit to the main view:

Commit changes into .../branches/experimental.

>    svn switch http://.../trunk

This switches the base of the working copy back to .../trunk
and applies the differences between .../branches/experimental
and .../trunk to the working copy (if there are any differences).

>    svn merge -r REV:HEAD http://.../branches/experimental

This is where I get lost.  The above command is the same as

   svn merge http://.../branches/experimental@REV \
             http://.../branches/experimental@HEAD .

which means merge the diffs of the entire experimental branch
into the working copy.  Why is this command necessary.  Aren't
these changes already in the working copy?

>    svn commit -m '* Merging in experimental changes'

Commit the combined trunk and experimental branches back to
.../trunk.

I must have some misunderstanding of the merge command (and
perhaps switch also).  I've reread the pertinent sections of
the new handbook but it doesn't seem to help.

-- 
Tim Moloney
ManTech Real-time Systems Laboratory
2015 Cattlemen Road                             \     /
Sarasota, FL  34232                     .________\(O)/________.
(941) 377-6775 x208                        '  '  O(.)O  '  '


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jul 24, 2002 at 10:20:11PM -0400, William Uther wrote:
>...
> In the post-1.0 feature set is the concept of storing in properties what
> gets merged where.  It might be interesting if 'svn log -v' parsed these
> properties, retrieved the appropriate log messages, and output them too.

Yup. Great idea. Would you mind entering your thoughts into the issue
tracker? As maybe an "enhancement" or "feature".

Thx,
-g

-- 
Greg Stein, http://www.lyra.org/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by cm...@collab.net.
William Uther <wi...@cs.cmu.edu> writes:

> On 24/7/02 9:02 PM, "cmpilato@collab.net" <cm...@collab.net> wrote:
> 
> > Peter Schuller <pe...@infidyne.com> writes:
> > 
> >> 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.
> > 
> > What you are describing is exactly what the "branch" concept means.
> 
> Hmm.  I got one thing more out of his post.  I'm not sure if this is what he
> meant, but...
> 
> When you merge, you compress the log messages of the individual commits into
> a single log message: "merging branch foo, revisions bar through baz".  It
> would be nice if 'svn log' could pull this information back out for you.
> 
> In the post-1.0 feature set is the concept of storing in properties what
> gets merged where.  It might be interesting if 'svn log -v' parsed these
> properties, retrieved the appropriate log messages, and output them too.

Sure, +1 and all that.  Post-1.0. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by Peter Schuller <pe...@infidyne.com>.
> Hmm.  I got one thing more out of his post.  I'm not sure if this is what he
> meant, but...
> 
> When you merge, you compress the log messages of the individual commits into
> a single log message: "merging branch foo, revisions bar through baz".  It
> would be nice if 'svn log' could pull this information back out for you.

Thank you... you put it a helluva lot more nicely than me :) That's
exactly the problem I'm trying to work around. I.e., doing an 'svn log'
on the trunk should show as much log information regardless of wheather
all development was performed in the trunk or in other branches and then
merged into it.

The reason our group that I mentioned didn't go for this solution was
exactly that - we did not want the CVS logs to just contain "merged ..."
all the time, having to hunt for the actual changes in the branches.
 
-- 
/ Peter Schuller, InfiDyne Technologies HB

PGP userID: 0xE9758B7D or 'Peter Schuller <pe...@infidyne.com>'
Key retrival: Send an E-Mail to getpgpkey@scode.org
E-Mail: peter.schuller@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

Re: Feature idea: Hierarchal logs (views? subrevisions?)

Posted by William Uther <wi...@cs.cmu.edu>.
On 24/7/02 9:02 PM, "cmpilato@collab.net" <cm...@collab.net> wrote:

> Peter Schuller <pe...@infidyne.com> writes:
> 
>> 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.
> 
> What you are describing is exactly what the "branch" concept means.

Hmm.  I got one thing more out of his post.  I'm not sure if this is what he
meant, but...

When you merge, you compress the log messages of the individual commits into
a single log message: "merging branch foo, revisions bar through baz".  It
would be nice if 'svn log' could pull this information back out for you.

In the post-1.0 feature set is the concept of storing in properties what
gets merged where.  It might be interesting if 'svn log -v' parsed these
properties, retrieved the appropriate log messages, and output them too.

E.g:

   svn commit -m '* Did originial stuff'   (rev 1)
   svn copy -m 'make experimental branch' \
                          http//.../trunk http://.../branches/experimental
(rev 2)
   ... remember the revision number we just created here as REV ...
   svn switch http://.../branches/experimental
   ... do various stuff, commit changes, etc:
   svn commit -m '* Did something' (rev 3)
   ... Someone else commits to the head making rev 4
   svn commit -m '* Did something else' (rev 5)
   ... decide to commit to the main view:
   svn switch http://.../trunk
   svn merge -r REV:HEAD http://.../branches/experimental
   svn commit -m '* Merging in experimental changes' (rev 6)
   ... Do more stuff
   svn commit -m '* Did another something' (rev 7)

Then:  (and I've forgotten the correct format)

svn log -v

----------
Rev 7: * Did another something
----------
Rev 6: * Merging in experimental changes

Merged logs (revs 2 through 5):
     ----------
     Rev 5: * Did something else
     ----------
     Rev 3: * Did something
     ----------
     Rev 2: make experimental branch
----------
Rev 4: * Some stuff done by your friend
----------
Rev 1: * Did originial stuff

Later,

\x/ill        :-}



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org