Possible new feature

[Noel Torres <en...@rolamasao.org>]

I'm not subscribed, so please CC me in the answer

If a svn user decides to divide a bunch of code into two files, it's an 
easy task to accomplish using

$ svn copy a_lot.c small_2.c
$ svn move small_1.c
then editing both small_*.c to delete the nonwanted section in each one, 
and then
$ svn commit a_lot.c small_1.c small_2.c

That way both small_1.c and small_2.c have the revision history of a_lot.c
This is implemented actually.

¿But what if the svn-using developer wnat to JOIN the code of two files 
into one of them? This can happen if you have separate files during 
developing and want a single source code to release, or if you are 
taking code from several places of your repository to implement a new 
feature, but closely related to two actual pieces of code. Or simply if 
you are reorganizing a project.

Can this be implemented in SVN? Maybe a 'svn join <main_small_source> 
<secondary_small_source> <destiny_big_source>' command which takes the 
history of its first argument, the log messages of first and second 
arguments signaling them with '<name>:\n' and puts the adequate marks in 
both three files' history.

I'm writing this just because I've just needed that feature, and had to 
use several 'svn copy <piece> .', then edit them all to delete unwanted 
stuff, then 'cat <all but one pieces> > <main piece>' 'svn --force move 
<main piece> <destiny>' and 'svn delete <all but one -yet deleted- pieces>'.

Thanks for any answer

Noel Torres

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

Re: Possible new feature

[Noel Torres <en...@rolamasao.org>]

I'm not subscribed, so please CC me in the answer


C. Michael Pilato wrote:

>I remember chatting about this feature in the past.  It's certainly
>do-able.  And seems useful, too.  The complication that I see is that
>your destination file will have a fork in its ancestry, which means
>that answer questions like, "What did this line of history look like
>in <some revison prior to the join>?" kinda complicated.  Does the
>answer include data from both tines of the fork (or all N of them,
>right -- this operation can commute)?
>
>Not that this is a new problem.  We have the problem today, in trying
>to answer "What does this line of history look like in <some revision
>after a copy/branching operation>?"
>  
>

Possible answer: let 'svn join <A> <B>'  behave as 'cat <B> >> <A>'
That solves the problem about "from which revision comes this line". 
This way a complete history for teh file can be generated. Let the user 
do his reordering after that, as he can do to any single file. If you 
want to know abot the history of the complete file (where it has been 
trough several 'svn move') the history of file <A> will be used. Another 
idea is a unversioned property svn:joined that can be used in some way.

Thanks

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

Re: Possible new feature

[Greg Hudson <gh...@MIT.EDU>]

On Sat, 2004-12-18 at 21:09, Branko Čibej wrote:
> Greg Hudson wrote:
> >You "got shot down" partly because this is an incomplete proposal. 
> >svn_repos_trace_node_locations could return multiple paths, but what
> >would be the behavior of "svn cat -r10000 url@9000" if it does so?
> >
> Sorry, I don't see the relevance here. The one is an API, the other is a 
> decision about GUI behaviour.

svn_repos_trace_node_locations is a UI-directed subroutine.  It exists
precisely to efficiently compute what "svn command -rX foo@Y" should
do.  (If performance were not an issue, we could do the same thing with
ra_lib->do_log, and we do that against a 1.0 server.)  So a complete
proposal as to changing its behavior includes the corresponding change
in UI behavior.


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

Re: Possible new feature

[Branko Čibej <br...@xbc.nu>]

Greg Hudson wrote:

>On Fri, 2004-12-17 at 05:15, Branko ÄŒibej wrote:
>  
>
>>that is, svn_repos_trace_node_locations returns only one path per 
>>revision, searching only the branch defined by teh fs path and peg. I 
>>argued that it should return a set of paths per revision, but got shot 
>>down there, too.
>>    
>>
>
>You "got shot down" partly because this is an incomplete proposal. 
>svn_repos_trace_node_locations could return multiple paths, but what
>would be the behavior of "svn cat -r10000 url@9000" if it does so?
>
Sorry, I don't see the relevance here. The one is an API, the other is a 
decision about GUI behaviour.

>Do
>we get a copy of url on the trunk and every branch which has been
>created between 9000 and 10000?
>
>I argued that we should have true rename support, and forward tracing
>should follow renames but not copies.
>
"Renames and branches but not copies." But I'm getting way out of the 
domain of possible 1.x fixes. We can't have efficient forward searches 
without a schema change anyway.

>  I think backward tracing should
>follow renames and copies but not merges.  Perhaps a join could be seen
>as a merge.
>
Theoretically speaking, a join has about as much in common with a merge 
as a copy does with a branch. I hope to persuade people about the 
importance of these differences before 2.0 gets set in stone, but since 
that's a long way off, this may not be the right time.

-- Brane



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

Re: Possible new feature

[Greg Hudson <gh...@MIT.EDU>]

On Fri, 2004-12-17 at 05:15, Branko Čibej wrote:
> Not exactly, IIRC we ignore branches when tracing node history forwards;

We don't trace node history forwards, because we have no efficient way
of doing so.  We have a heuristic where we check that <peg-rev,path> and
<new-rev,path> refer to the same object, and return <new-rev,path> if it
does.

> that is, svn_repos_trace_node_locations returns only one path per 
> revision, searching only the branch defined by teh fs path and peg. I 
> argued that it should return a set of paths per revision, but got shot 
> down there, too.

You "got shot down" partly because this is an incomplete proposal. 
svn_repos_trace_node_locations could return multiple paths, but what
would be the behavior of "svn cat -r10000 url@9000" if it does so?  Do
we get a copy of url on the trunk and every branch which has been
created between 9000 and 10000?

I argued that we should have true rename support, and forward tracing
should follow renames but not copies.  I think backward tracing should
follow renames and copies but not merges.  Perhaps a join could be seen
as a merge.


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

Re: Possible new feature

[Branko Čibej <br...@xbc.nu>]

C. Michael Pilato wrote:

>I remember chatting about this feature in the past.  It's certainly
>do-able.  And seems useful, too.
>
Heh, last time I tried to convince people that node history is a DAG, 
not a tree, I got shot down on the grounds that "you get the same effect 
by merging the contents then deleting the branch". :-)

>  The complication that I see is that
>your destination file will have a fork in its ancestry, which means
>that answer questions like, "What did this line of history look like
>in <some revison prior to the join>?" kinda complicated.  Does the
>answer include data from both tines of the fork (or all N of them,
>right -- this operation can commute)?
>
>Not that this is a new problem.  We have the problem today, in trying
>to answer "What does this line of history look like in <some revision
>after a copy/branching operation>?"
>  
>
Not exactly, IIRC we ignore branches when tracing node history forwards; 
that is, svn_repos_trace_node_locations returns only one path per 
revision, searching only the branch defined by teh fs path and peg. I 
argued that it should return a set of paths per revision, but got shot 
down there, too.

But anyway, I think this is _not_ doable without a schema change. As you 
might have guessed, this kind of schema change is bubbling away in my 
pot of ideas for 2.0. But it'll be a while yet before /that/ gets 
served. :-)

-- Brane



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

Re: Possible new feature

["C. Michael Pilato" <cm...@collab.net>]

I remember chatting about this feature in the past.  It's certainly
do-able.  And seems useful, too.  The complication that I see is that
your destination file will have a fork in its ancestry, which means
that answer questions like, "What did this line of history look like
in <some revison prior to the join>?" kinda complicated.  Does the
answer include data from both tines of the fork (or all N of them,
right -- this operation can commute)?

Not that this is a new problem.  We have the problem today, in trying
to answer "What does this line of history look like in <some revision
after a copy/branching operation>?"


Noel Torres <en...@rolamasao.org> writes:

> I'm not subscribed, so please CC me in the answer
> 
> If a svn user decides to divide a bunch of code into two files, it's
> an easy task to accomplish using
> 
> $ svn copy a_lot.c small_2.c
> $ svn move small_1.c
> then editing both small_*.c to delete the nonwanted section in each
> one, and then
> $ svn commit a_lot.c small_1.c small_2.c
> 
> That way both small_1.c and small_2.c have the revision history of a_lot.c
> This is implemented actually.
> 
> ¿But what if the svn-using developer wnat to JOIN the code of two
> files into one of them? This can happen if you have separate files
> during developing and want a single source code to release, or if you
> are taking code from several places of your repository to implement a
> new feature, but closely related to two actual pieces of code. Or
> simply if you are reorganizing a project.
> 
> Can this be implemented in SVN? Maybe a 'svn join <main_small_source>
> <secondary_small_source> <destiny_big_source>' command which takes the
> history of its first argument, the log messages of first and second
> arguments signaling them with '<name>:\n' and puts the adequate marks
> in both three files' history.
> 
> I'm writing this just because I've just needed that feature, and had
> to use several 'svn copy <piece> .', then edit them all to delete
> unwanted stuff, then 'cat <all but one pieces> > <main piece>' 'svn
> --force move <main piece> <destiny>' and 'svn delete <all but one -yet
> deleted- pieces>'.
> 
> Thanks for any answer
> 
> Noel Torres
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

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