You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Paul Maier <sv...@web.de> on 2011/01/21 03:26:49 UTC
how to find out from where a file has been copied
Hi,
a question.
Imagine the following:
svn mv 1 a
svn mv 2 b
svn cp -r 456 3 c
then modify the files for a while.
svn st will output something like:
D 1
D 2
A+ a
A+ b
A+ c
How do I see if file "a" came from 1 or from 2?
How do I see from which revision of file 3 came file c?
After the check-in, it's clear: svn log will show it.
How do I review (if it's ok what I did) BEFORE checking-in?
Thanks for advice!
Paul.
Re: how to find out from where a file has been copied
Posted by JamieEchlin <ja...@credit-suisse.com>.
Stefan Sperling-7 wrote:
>
>> This would be lovely, and is what we're aiming for using tortoise
>> pre-commit
>> hooks and server hooks, although in a bit of a spit-and-sawdust way at
>> the
>> moment.
>
> I'd like to hear how that turns out.
>
> Will you be allowed to share these hooks under an open source licence?
>
Would love to, but I doubt it. Will speak to the relevant people though.
I will find a way to at least tangentially report how it's working, or not.
cheers, jamie
--
View this message in context: http://old.nabble.com/how-to-find-out-from-where-a-file-has-been-copied-tp30725288p30728122.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Re: how to find out from where a file has been copied
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 21, 2011 at 03:56:32AM -0800, JamieEchlin wrote:
>
>
>
> Stefan Sperling-7 wrote:
> >
> > It would be even nicer if Subversion had a way of guiding users to
> > perform merges in accordance with a pre-defined strategy.
> > So if the user tried to perform e.g. a cherry-picking merge to a branch
> > for which cherry-picking isn't defined in the strategy, svn would error
> > out and let the user know that this type of merge isn't allowed for the
> > merge target.
> >
>
> This would be lovely, and is what we're aiming for using tortoise pre-commit
> hooks and server hooks, although in a bit of a spit-and-sawdust way at the
> moment.
I'd like to hear how that turns out.
Will you be allowed to share these hooks under an open source licence?
Stefan
Re: how to find out from where a file has been copied
Posted by JamieEchlin <ja...@credit-suisse.com>.
Stefan Sperling-7 wrote:
>
> It would be even nicer if Subversion had a way of guiding users to
> perform merges in accordance with a pre-defined strategy.
> So if the user tried to perform e.g. a cherry-picking merge to a branch
> for which cherry-picking isn't defined in the strategy, svn would error
> out and let the user know that this type of merge isn't allowed for the
> merge target.
>
This would be lovely, and is what we're aiming for using tortoise pre-commit
hooks and server hooks, although in a bit of a spit-and-sawdust way at the
moment.
> But of course, educating users is a social problem, not a technical one.
> No technical solution will ever solve this completely.
>
Totally agree... I think the problem needs to be tackled on both the social
and technical fronts. You can socialise it til the cows come home but it
only takes one user to ride rough-shod over your carefully defined merging
strategy because they need to commit urgently to cause many problems going
forward.
cheers, jamie
--
View this message in context: http://old.nabble.com/how-to-find-out-from-where-a-file-has-been-copied-tp30725288p30727959.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Re: how to find out from where a file has been copied
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 21, 2011 at 02:59:37AM -0800, JamieEchlin wrote:
> Stefan Sperling-7 wrote:
> >
> > There is nothing that tells you this information directly.
> > The changes brought in by a merge are treated just like any other
> > local changes. As far as Subversion is concerned, you could have made
> > any merged changes manually.
> >
> > Defining a good branching/merging strategy, making sure everyone knows it,
> > and consistently keeping to it may help with avoiding such questions
> > in the first place.
> >
> > Stefan
> >
>
> OK, thanks.
>
> With respect, your second paragraph is a bit of a cop out. We do have a well
> defined branching and merging strategy, the problem is making sure everyone
> knows it and follows it, even in the heat of trying to get out a production
> fix on a Sunday.
>
> The development mentality in the corporate environment is not the same as in
> open source land, where people agonise over their commits for a long time
> because they know they're going to be peer-reviewed by many people.
>
> Some of the users here are not really programmers, they're rocket
> scientists, and they only write code as a side-effect of their main role.
> They expect things to just work, and they're too fantastically intelligent
> to learn how to respect the merging rules defined. So they keep telling us
> anyway.
:)
> I exaggerate but I hope you see my point... we do spell these things out but
> we need the big stick too.
Good point. Documenting the strategy is only part of the problem in real
life. So it would help if Subversion had a better way of letting people
know that the strategy is being followed.
It would be even nicer if Subversion had a way of guiding users to
perform merges in accordance with a pre-defined strategy.
So if the user tried to perform e.g. a cherry-picking merge to a branch
for which cherry-picking isn't defined in the strategy, svn would error
out and let the user know that this type of merge isn't allowed for the
merge target.
Neither would be trivial to design and implement, but both could
be possible.
But of course, educating users is a social problem, not a technical one.
No technical solution will ever solve this completely.
If rocket scientists were perfect, there wouldn't be a problem.
Stefan
Re: how to find out from where a file has been copied
Posted by JamieEchlin <ja...@credit-suisse.com>.
Stefan Sperling-7 wrote:
>
> There is nothing that tells you this information directly.
> The changes brought in by a merge are treated just like any other
> local changes. As far as Subversion is concerned, you could have made
> any merged changes manually.
>
> Defining a good branching/merging strategy, making sure everyone knows it,
> and consistently keeping to it may help with avoiding such questions
> in the first place.
>
> Stefan
>
OK, thanks.
With respect, your second paragraph is a bit of a cop out. We do have a well
defined branching and merging strategy, the problem is making sure everyone
knows it and follows it, even in the heat of trying to get out a production
fix on a Sunday.
The development mentality in the corporate environment is not the same as in
open source land, where people agonise over their commits for a long time
because they know they're going to be peer-reviewed by many people.
Some of the users here are not really programmers, they're rocket
scientists, and they only write code as a side-effect of their main role.
They expect things to just work, and they're too fantastically intelligent
to learn how to respect the merging rules defined. So they keep telling us
anyway.
I exaggerate but I hope you see my point... we do spell these things out but
we need the big stick too.
--
View this message in context: http://old.nabble.com/how-to-find-out-from-where-a-file-has-been-copied-tp30725288p30727591.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Re: how to find out from where a file has been copied
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 21, 2011 at 02:09:13AM -0800, JamieEchlin wrote:
>
>
> Stefan Sperling-7 wrote:
> >
> >> How do I see if file "a" came from 1 or from 2?
> >> How do I see from which revision of file 3 came file c?
> >>
> >> After the check-in, it's clear: svn log will show it.
> >>
> >> How do I review (if it's ok what I did) BEFORE checking-in?
> >
> > svn info a | grep ^Copied
> >
>
>
> I was going to ask a similar question, it's so similar that I'll tack it
> onto this.
>
> How do you find out from the working copy, either with svn subcommands or
> working copy api, what was the source(s) of a merge, before commiting?
>
> Of course, I can diff the svn:mergeinfo, and this works if just one line of
> it has changed. But if I merge from C to B to A, mergeinfo on A will have
> entries for both C and B... how can I tell which was the source of this
> merge?
There is nothing that tells you this information directly.
The changes brought in by a merge are treated just like any other
local changes. As far as Subversion is concerned, you could have made
any merged changes manually.
Defining a good branching/merging strategy, making sure everyone knows it,
and consistently keeping to it may help with avoiding such questions
in the first place.
Stefan
Re: how to find out from where a file has been copied
Posted by JamieEchlin <ja...@credit-suisse.com>.
Stefan Sperling-7 wrote:
>
>> How do I see if file "a" came from 1 or from 2?
>> How do I see from which revision of file 3 came file c?
>>
>> After the check-in, it's clear: svn log will show it.
>>
>> How do I review (if it's ok what I did) BEFORE checking-in?
>
> svn info a | grep ^Copied
>
I was going to ask a similar question, it's so similar that I'll tack it
onto this.
How do you find out from the working copy, either with svn subcommands or
working copy api, what was the source(s) of a merge, before commiting?
Of course, I can diff the svn:mergeinfo, and this works if just one line of
it has changed. But if I merge from C to B to A, mergeinfo on A will have
entries for both C and B... how can I tell which was the source of this
merge?
cheers, jamie
--
View this message in context: http://old.nabble.com/how-to-find-out-from-where-a-file-has-been-copied-tp30725288p30727243.html
Sent from the Subversion Users mailing list archive at Nabble.com.
Re: how to find out from where a file has been copied
Posted by Stefan Sperling <st...@elego.de>.
On Fri, Jan 21, 2011 at 03:26:49AM +0100, Paul Maier wrote:
> Hi,
>
> a question.
>
> Imagine the following:
>
> svn mv 1 a
> svn mv 2 b
> svn cp -r 456 3 c
>
> then modify the files for a while.
>
> svn st will output something like:
> D 1
> D 2
> A+ a
> A+ b
> A+ c
>
> How do I see if file "a" came from 1 or from 2?
> How do I see from which revision of file 3 came file c?
>
> After the check-in, it's clear: svn log will show it.
>
> How do I review (if it's ok what I did) BEFORE checking-in?
svn info a | grep ^Copied
Stefan