You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Molle Bestefich <mo...@gmail.com> on 2005/10/04 12:01:34 UTC
Re: Proposal for $Revision$ keyword amendment
David Waite and John Peacock discussed ambiguity related to mixed
revision working copys.
My proposal was and still is to simply fill in "mixed" or min:max
("100:200") in the event that a mixed revision working copy is
encountered.
People that deliberately use mixed revision working copys are not the
target audience for the feature anyway, so let's not discuss that
anymore if we can do without :-).
John Peacock further argued that the feature is impossible to
implement and that no-one would ever use it. I've already told a bit
about why I think that $UpdateRev$ would be a über cool feature, so
I'm not going to argue much more about that at the moment.
John Peacock further argued that the problem solved is not really a
big burden for anyone. I disagree - the way I see it, build
environments has to be tweaked and adapted into infinity whenever you
create a new project, start something in a new programming language or
want to put a new type of file in the repository. Plus there's the
costs associated with educating developers, which I could personally
live without. Plus I like the niceties of a platform and
build-environment independent solution, done using the same mechanism
that other Subversion keywords use, instead of various inferior custom
solutions. I'm Not going to enter into any more discussions about
this point either, if I can be without :-).
John Peacock wrote:
> If, instead, your description field contained the tag that the
> application was built off of, you would always be able to recreate any
> release.
Copy/pasting that release number from a tag name into the various source files
where it 'belongs' is one of the processes that I would be happy to be without.
I'll give you an example of where your approach is wrong.
The MyODBC project has in their last 2 or 3 (can't remember) official
releases had the wrong version number in their released DLLs. Some of
their releases even sported
the correct version number in some places, and the wrong one in other.
Automating that process using keywords would be a handy way of getting
rid of that problem altogether. That's a major point in using
keywords _at all_.
Granted, I can do 'svn info | grep URL: | awk -F/ '{print $NF'}' and
somehow stuff that into a file that will get compiled in. That
suffers from a lot of the same problems already mentioned for other
non-keyword-based proposals, and furthermore it doesn't work for
people releasing off trunk - think nightlies and the like.
> > > 1) Branch for the release, complete testing and any integration
> > > to the branch until ready to release.
> > >
> > > 2) Tag the branch and release off the tag, using a tag name
> > > which corresponds to the externally visible package name.
> >
> > That's highly impractical for small projects or
> > projects that are released often.
>
> I strongly disagree. Even if you don't have a firm testing scheme (and
> you should), you can easily skip step 1 and just tag/switch/release.
Oh, ok. Misunderstanding. In that case, that's exactly what we currently do.
Greg Hudson wrote:
[ snipped: clear thinking wrt performance issues ]
> The new keyword value would remain accurate: it would reflect the
> working copy revision of that file. It might not reflect the uniform
> revision of the entire working copy, but we don't have to make that a
> requirement. (Although a name like $GlobalRev$ would probably be a poor
> choice. $WCRev$ would be accurate but still easy to misinterpret;
Right. Agreed.
> $UpdateRev$ is inelegant but makes a certain amount of sense.
> There are probably better choices I haven't thought of.)
Related to that, I'd like to point out an ambiguity (the only one, as I see it).
I was thinking that svn commit should also expand $UpdateRev$,
consistent with what's currently done. Consider however the case
where svn commit is executed on a whole directory. File ABC has
changed, file XYZ contains the $UpdateRev$ keyword. The user will
only be presented with the file that has changes, but to be consistent
with 'svn update', we might want to expand the keywords in the
non-changed file, since the 'commit' action was performed on the
folder containing both items.
I'm not sure how to solve that. One way is to not expand keywords in
the non-changed files, which seems inconsistent with what the user
actually asked for, but might be more in line with what the user
*expects* to happen. Hmm.
Expanding keywords in non-changed files, OTOH, at first seems like a
bad idea, as there is no feedback to the user telling h(im/er) that
any changes was done related to that file.
Thinking a bit more about it, though, the idea becomes a lot more
appealing. Feedback should just be added, but it would be a rather
large alteration of the meaning of 'svn commit' output to call it 'M'
for file modifications. A new flag 'K' could be added to the output,
meaning "you asked to commit this file; it had no changes but we
expanded it's working copy related keywords".
Thoughts?
Marc Sherman wrote:
> Should a file with this keyword in it automatically get modified
> locally every time it's updated, even if there are no remote changes?
If it's included as a target of the update, yes, certainly.
> Should all files be scanned for this keyword so that update knows
> to hit them in this unusual way, or should there be an svn property
> that controls this?
It should of course be controlled by the svn:keywords property, just
like other keywords.
> What happens when there's a commit in the working copy; should this file
> be updated by svn commit as well as svn update?
That already happens as it is now. I have no plans of changing that.
(Actually, you are prevented from committing a file it you have not
updated to it's last committed revision in the repository.)
> What happens if the commit is in a non-local part of the working copy
> (ie: the magic property is in ...wc/foo/bar/magic.txt, and there's an
> svn commit in ...wc/baz/)?
If you svn commit '/wc/baz/', keywords do not get updated in '/wc/foo/'.
Greg Hudson wrote:
> Max was operating on the assumption that "svn update onefile" would have
> to do additional work because he was imagining a keyword whose value
> reflected the state of the entire wc at all times. I don't think users
> are asking for that level of assurance.
For the record, I agree completely.
In our projects, we have no need for that.
John Peacock wrote:
> It's hard enough to convince
> people that keywords are bound to files, and hence only get updated when
> that file gets updated. Once you give them access to a global status
> keyword, the inevitable next question is "Why can't I get that file
> updated automatically in all files that have it?"
The answer to that question is hopefully the same in both cases.
"Files that you target with a 'svn' operation will be modified, others
we leave alone."
> All you have to do is look at the number of questions on the users list
> about why $Revision$ doesn't get globally updated (since many people
> initially believe that to be the repository rev not the file rev).
Those people are probably most confused about how stupid the
$Revision$ keyword seems once they find out what it does. From a
usability, not a technical POV that is. Telling them that there's
actually something that does what they want, which is $UpdateRev$,
would be great.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Vincent Starre <vs...@comcast.net>.
Molle Bestefich wrote:
>Granted, I can do 'svn info | grep URL: | awk -F/ '{print $NF'}' and
>somehow stuff that into a file that will get compiled in. That
>suffers from a lot of the same problems already mentioned for other
>non-keyword-based proposals, and furthermore it doesn't work for
>people releasing off trunk - think nightlies and the like.
>
>
>
faced with the same situation, I put that line into the makefile. (well,
I used svnversion for what I was doing)
what you seem to be describing is the $HeadURL keyword, there.
of course, in that same file, we also put the copyright, build date,
etc. The only drawback was making a commit which changed every file to
include build.h- so I had to update everywhere! (what? I'm lazy!)
I havent been reading the thread, so I'm sure you've already mentioned
reasons why that's unacceptable (*and I'm also of the "don't force
people to come up with solutions that would make much more sense as a
built-in feature" mindset)
In our build, we call the version returned by svnversion the "global
revision", and (*opinion) it really doesnt make sense to associate
whole-directory information with a file.
of course, the "Global Revision" doesnt show up in the source files
themselves, but one can tend to assume that those who have the source
already know where they got it from :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Molle Bestefich <mo...@gmail.com>.
Marc Sherman wrote:
> Molle Bestefich wrote:
> > People that deliberately use mixed revision working copys are not the
> > target audience for the feature anyway, so let's not discuss that
> > anymore if we can do without :-).
>
> I think you've missed the point about mixed revision working copies.
> Running "svn commit" creates a mixed revision WC -- the files committed
> will be the new revision, while all other files will be untouched. So
> if your feature doesn't target mixed revision WCs, then it doesn't
> target anyone who commits.
*Sigh*.
Ok, I'll rephrase myself ;-).
The feature doesn't target anyone who actually wants to *release* from
a working copy where they have *purposedly* checked out different
revisions of different files.
The feature DOES target everybody else, as long as they do an update
on their trunk or checkout a tag before releasing.
Better?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Marc Sherman <ms...@projectile.ca>.
Molle Bestefich wrote:
> David Waite and John Peacock discussed ambiguity related to mixed
> revision working copys.
>
> My proposal was and still is to simply fill in "mixed" or min:max
> ("100:200") in the event that a mixed revision working copy is
> encountered.
>
> People that deliberately use mixed revision working copys are not the
> target audience for the feature anyway, so let's not discuss that
> anymore if we can do without :-).
I think you've missed the point about mixed revision working copies.
Running "svn commit" creates a mixed revision WC -- the files committed
will be the new revision, while all other files will be untouched. So
if your feature doesn't target mixed revision WCs, then it doesn't
target anyone who commits.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by John Peacock <jp...@rowman.com>.
kfogel@collab.net wrote:
> I think John was just transmitting what he felt Molle Bestefich was
> proposing.
You've got that exactly right; I'm sorry I didn't make it clear. I'm
trying to translate Molle's requested functionality (as a user) into the
existing Subversion codebase (from a development point of view) to show
that the functionality, as requested, would be a significant departure.
That being said, this whole discussion has given me some insights into
fixing the 'svn switch' keywords expansion problem. I don't expect I'll
have the time to do the actual coding, but I'm going to try and describe
what I am thinking about and add it to the issue for someone else to use.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by kf...@collab.net.
Molle Bestefich <mo...@gmail.com> writes:
> > If not, could you post one? What's described in
> >
> > http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106102
> >
> > is completely uncompelling (to me, anyway). I'm -1 on it. But maybe
> > the proposal has evolved since then?
>
> Yes, it has. I've learned a lot especially from Greg's comments, but
> also from everybody else's contributions to the discussion. I'd be
> happy to spend some time making a clearer proposal.
>
> If you have some comments on why you're -1 which haven't been
> mentioned, I would of course appreciate hearing them.
I think they've all been mentioned by others in this thread.
Best,
-karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Molle Bestefich <mo...@gmail.com>.
kfogel wrote:
> I think John was just transmitting what he felt Molle Bestefich was
> proposing.
There were a lot of feelings in it all right :-).
John Peacock wrote:
> You've got that exactly right; I'm sorry I didn't make it clear. I'm
> trying to translate Molle's requested functionality (as a user) into the
> existing Subversion codebase (from a development point of view) to show
> that the functionality, as requested, would be a significant departure.
I think that you've on more than one occasion gravely misunderstood
what functionality I'm requesting.
Don't get me wrong - I appreciate your feedback very much!
> However, maybe we're misunderstanding what Molle wants?
>
> Molle, is there a mail that contains a complete (edge-cases included)
> description of the feature proposal as it stands right now?
No.
> If not, could you post one? What's described in
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106102
>
> is completely uncompelling (to me, anyway). I'm -1 on it. But maybe
> the proposal has evolved since then?
Yes, it has. I've learned a lot especially from Greg's comments, but
also from everybody else's contributions to the discussion. I'd be
happy to spend some time making a clearer proposal.
If you have some comments on why you're -1 which haven't been
mentioned, I would of course appreciate hearing them.
Regards,
/me
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> No, we cannot make it magically update to reflect the mixed-rev state of
> a working copy without making unacceptable architectural compromises.
>
> If your argument is "this feature is worthless unless it does all the
> magic we can't do", then that's consistent (though not compelling, to
> me). But what's frustrating is that you're not phrasing your argument
> that way. You're assuming I want to do the impossible magic, arguing
> that it can't be done, and leaving it at that.
I think John was just transmitting what he felt Molle Bestefich was
proposing.
I too get the feeling that what Molle wants can't easily be done in
Subversion, and that the best answer is to use the 'svnversion'
program (which was, after all, written to be a workaround for exactly
this problem). However, maybe we're misunderstanding what Molle wants?
Molle, is there a mail that contains a complete (edge-cases included)
description of the feature proposal as it stands right now? If not,
could you post one? What's described in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=106102
is completely uncompelling (to me, anyway). I'm -1 on it. But maybe
the proposal has evolved since then?
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-10-04 at 15:39 -0400, John Peacock wrote:
> I also don't think you've thought this through all that much either.
Then I think you haven't been reading what I've written in this thread,
or not understanding it.
> But it is
> trivial to come up with a scenario that will not work correctly that way:
>
> $ svn co project1
> $ cd project1
> $ vi lib/some/deep/directory/file1.c
> $ svn ci -m 'look Ma, no recursive checkin' lib/some/deep/directory/file1.c
> $ make
That would work correctly. The top-level include file with $UpdateRev$
in it correctly reflects the *working copy revision of that file*, as
recorded in the entries file. Only when we change the entry for a file
do we have to worry about re-expanding its $UpdateRev$ keywords.
No, we cannot make it magically update to reflect the mixed-rev state of
a working copy without making unacceptable architectural compromises.
If your argument is "this feature is worthless unless it does all the
magic we can't do", then that's consistent (though not compelling, to
me). But what's frustrating is that you're not phrasing your argument
that way. You're assuming I want to do the impossible magic, arguing
that it can't be done, and leaving it at that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by John Peacock <jp...@rowman.com>.
Greg Hudson wrote:
> You're oversimplifying. $UpdateRev$ would require additional machinery
> to implement, but it would not imply any tremendous architectural or
> performance issues.
Yes, I am oversimplifing, because Molle seems to expect that Subversion can
somehow magically know which files contain $UpdateRev$ and update those files
even when they have not otherwise changed.
I also don't think you've thought this through all that much either. Yes, it
would be possible to check the entries file to locate the files with the
UpdateRev keyword for substitution during the normal update process. But it is
trivial to come up with a scenario that will not work correctly that way:
$ svn co project1
$ cd project1
$ vi lib/some/deep/directory/file1.c
$ svn ci -m 'look Ma, no recursive checkin' lib/some/deep/directory/file1.c
$ make
Now unfortunately, the top level include file with $UpdateRev$ was not part of
that commit, so Subversion has no way to update it unless the entire WC is read
(granted just the entries files). That has to be some performance hit, even if
you don't think it is significant.
Additionally, only by scanning the entire WC can you even determine what value
should be plugged in to that field. Consequently, even if you enumerate the
files that need updating, an additional loop after the normal check-in
processing would be required to substitute that value. I would argue that this
is a significant architectural change, since all of the current code operates
under the "I'm here, this is what I know, this is what I need to do" mode of
operation, completely oblivious to the rest of the WC.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2005-10-04 at 14:01 +0200, Molle Bestefich wrote:
> I was thinking that svn commit should also expand $UpdateRev$,
> consistent with what's currently done. Consider however the case
> where svn commit is executed on a whole directory. File ABC has
> changed, file XYZ contains the $UpdateRev$ keyword. The user will
> only be presented with the file that has changes, but to be consistent
> with 'svn update', we might want to expand the keywords in the
> non-changed file, since the 'commit' action was performed on the
> folder containing both items.
Because of our server-side auto-merging system, "commit" has to result
in a mixed-rev working copy. The $UpdateRev$ of an unchanged file still
needs to reflect the old, pre-commit version, because that file has not
been updated to the new revision. Remember that such a file may have
changed in the repository as part of an intervening commit.
There is a certain style of workflow which would be better served by a
system which has no auto-merge and which does not create mixed-revision
working copies on commit (every commit updates the current revision by
1, and the working copy knows exactly what is in that revision after a
commit), but Subversion does not operate in that mode.
John Peacock wrote:
> I'm not sure how many other ways I can say this: Subversion has no
> way to permit updating keywords in otherwise unchanged files.
You're oversimplifying. $UpdateRev$ would require additional machinery
to implement, but it would not imply any tremendous architectural or
performance issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by John Peacock <jp...@rowman.com>.
Molle Bestefich wrote:
> I'm not trying to shoehorn it in, I'm trying to find out what's the
> cleanest possible way to do it.
I said "shoehorn" because you've decided on the solution before you've fully
examined the problem. Rather than looking at the architecture that exists now,
and why it works the way it does, you want to add something off to the side
whose sole purpose is to accomplish your task, even though there are existing
ways to do it that don't involve changing anything, except your chosen project
management style.
>>It's just not an acceptable performance penalty to potentially change every
>>single file on the off chance that one of them needs keywords expanded.
>
>
> I'm not sure where you're coming from.
> Who ever talked about changing every file?
> Only files with UpdateRev in their svn:keywords will get have
> expansion performed.
> Please clarify your concern.
The Subversion WC does not contain a master catalog of all files. Each
directory contains admin files that describe files in that directory alone.
Thus, the only way to ensure that all files in a given WC are postprocessed as
you suggest is to walk the WC (see my message to Greg) on every checkin.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by Molle Bestefich <mo...@gmail.com>.
John Peacock wrote:
> I'm not sure how many other ways I can say this: Subversion has no way to
> permit updating keywords in otherwise unchanged files. That is "action at a
> distance" and is much worse than suggesting developers use their build system
> appropriately.
Not now at least, which is why I made a proposal at all.
Regarding build systems, see below.
> The concept you are trying to shoehorn into Subversion, 'last commit for this
> WC', is _project_ meta-data in that it doesn't apply to any specific file but
> rather to all files.
I'm not trying to shoehorn it in, I'm trying to find out what's the
cleanest possible way to do it.
> As such, it is best handled outside of Subversion's
> keywords handling itself, which is completely _file_ oriented.
I'm well aware that $UpdateRev$ would not, from a purely technical
POV, be implemented in exactly the same way that all the current
Subversion keywords are.
That's what I can do for you here - tell you what users (not you,
John) really need and get your minds off of the technical details for
a moment.
> Any given build system only needs a single methodology to handle expanding
> this value in whatever file needs to be expanded (an include file can be used
> in whatever files need the value in question so that there is only a single change
> required).
It's not that you're 100% wrong here, it's just that not every build
system supports the approach you have in mind. It's also that there's
considerable effort if you have a lot of different projects that each
has their own build system, as we do. We clearly disagree whether the
entire keyword is a good idea, so let's just agree to disagree and
spare the list for the same spam over and over again?
> > > keyword, the inevitable next question is "Why can't I get
> > > that file updated automatically in all files that have it?"
> >
> > The answer to that question is hopefully the same in both cases.
> > "Files that you target with a 'svn' operation will be modified, others
> > we leave alone."
>
> $ svn ci -m 'This commit recursively targets all files below here'
>
> It's just not an acceptable performance penalty to potentially change every
> single file on the off chance that one of them needs keywords expanded.
I'm not sure where you're coming from.
Who ever talked about changing every file?
Only files with UpdateRev in their svn:keywords will get have
expansion performed.
Please clarify your concern.
Greg Hudson covered some of the performance aspects, perhaps read his
postings if you have not already.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposal for $Revision$ keyword amendment
Posted by John Peacock <jp...@rowman.com>.
Molle Bestefich wrote:
> Expanding keywords in non-changed files, OTOH, at first seems like a
> bad idea, as there is no feedback to the user telling h(im/er) that
> any changes was done related to that file.
> Thinking a bit more about it, though, the idea becomes a lot more
> appealing. Feedback should just be added, but it would be a rather
> large alteration of the meaning of 'svn commit' output to call it 'M'
> for file modifications. A new flag 'K' could be added to the output,
> meaning "you asked to commit this file; it had no changes but we
> expanded it's working copy related keywords".
I'm not sure how many other ways I can say this: Subversion has no way to
permit updating keywords in otherwise unchanged files. That is "action at a
distance" and is much worse than suggesting developers use their build system
appropriately.
The concept you are trying to shoehorn into Subversion, 'last commit for this
WC', is _project_ meta-data in that it doesn't apply to any specific file but
rather to all files. As such, it is best handled outside of Subversion's
keywords handling itself, which is completely _file_ oriented. Any given build
system only needs a single methodology to handle expanding this value in
whatever file needs to be expanded (an include file can be used in whatever
files need the value in question so that there is only a single change required).
>>keyword, the inevitable next question is "Why can't I get that file
>>updated automatically in all files that have it?"
>
>
> The answer to that question is hopefully the same in both cases.
> "Files that you target with a 'svn' operation will be modified, others
> we leave alone."
$ svn ci -m 'This commit recursively targets all files below here'
It's just not an acceptable performance penalty to potentially change every
single file on the off chance that one of them needs keywords expanded.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org