You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by TBrowder <tb...@cox.net> on 2004/03/17 11:53:25 UTC
Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision Aliases)
I appreciate all the comments, and have no defense except I read the developer section of the book as well as HACKING and obviously didn't read them thoroughly enough. I will make the corrections suggested and resubmit. (And Julian, thanks for your kind words.)
However, before I resubmit the patch, I'll discuss my proposal in more detail.
Sometime last year (on the users list) I asked about three features we use heavily with CVS:
CVSROOT
Allows an administrator an easy way to point to the repository. Allows users a default location (svn URL) for their primary repository. I'm not a touch typist and use aliases a lot. I can easily switch repositories with a two- or three-character alias (under tcsh).
.cvsignore
I've tried the method described in the book and (1) it didn't work and (2) I don't agree with it.
rtag (and the command 'cvs history -T')
Allows a quick glance at milestones of a project without cluttering up the repository tree with changeable tags. Not changeable by the user. Output of 'cvs history -T' is guaranteed to be in reverse chronological order.
Most replies from responders (mostly developers) said words to the effect that no one used such commands because svn has another way to do it and besides, they didn't agree with them. In addition, the primary effort was to get version one out the door before much thought was given to new features. My reply was that my users (myself included) basically use CVS in a linear manner and tag major stages in the history of a project, and these three features (non of which svn has in a straight-forward manner) will be highly desirable in a CVS replacement. And I offered to make the features available. Since then I have seen other responders on the users list mention some of theses features as desirable (SVNROOT and .svnignore).
Then, in the last few days, I put together the first of my proposals (SVNROOT):
The idea is to use SVNROOT (where defined) as it is used in CVS as we commonly use it, to wit:
'cvs co module' (equates to 'svn co URL_to_repos/module')
'cvs import module [...and other args] (equates to 'svn import URL_to_repos/module' without a local directory)
To the best of my knowledge, svn and cvs default behaviors for other commands are similar and don't need a reference to SVNROOT because they both know the default repository location when the user is in a directory with a working copy (WC).
My idea for the implementation of SVNROOT in svn is to intercept the command line targets at the point just before they are checked for errors and execution (in the files './subversion/clients/cmdline/checkout-cmd.c' and './subversion/clients/cmdline/import-cmd.c' ), check to see if SVNROOT is defined, and make the appropriate substitutions in targets (if they are not already in URL format), and pass the arguments on as usual.
I believe the mod is innocuous, helpful to those who want such a feature, and can be ignored by those who don't.
So ends my proposal for SVNROOT.
In the future I shall propose implementation of the other two features I would like. Here are my initial thoughts on those:
.svnignore
Similar to CVS except better (allow .svnignore to apply to directories): When the default 'svn status' command is given, for each directory first check for the presence of the file '.svnignore' and use the limited regular expressions inside to check files and dirs that are unknown to svn (for "recursive" behavior, require an absolute or relative path to the file expression). Do not include those files in the resulting list.
rtag
The best idea I can come up with is to add the capability for an alias for a revision (but, better than CVS, with a larger allowable character set) and it would appear (if defined) in the log listing. A new alias may also be added at a later date. I think it should not be changeable (except for additions) by anyone except the administrator. The alias should be able to be used in any svn command that uses a revision number or date. The log listing command should have a switch to avoid showing entries without a revision alias.
I see where one of the desirable featues of svn is to enable easy use of scripts to add locally desired policies, etc., but I think the features I've proposed (which are well-established in CVS) should be part of the svn core.
In summary, svn is a great product and I want to use it to replace cvs for our use. We have grown accustomed to certain features of cvs that are not directly offered in the current version of svn, and I want to help add those features.
Tom Browder
Re: Proposed New Feature '.svnignore'
Posted by Max Bowsher <ma...@ukf.net>.
TBrowder wrote:
> I appreciate all the comments, and have no defense except I read the
> developer section of the book as well as HACKING and obviously didn't read
> them thoroughly enough. I will make the corrections suggested and
resubmit.
> (And Julian, thanks for your kind words.)
>
> However, before I resubmit the patch, I'll discuss my proposal in more
detail.
>
> Sometime last year (on the users list) I asked about three features we use
> heavily with CVS:
It is good idea to keep email threads to a single concept. It makes the
discussion far easier to follow.
Accordingly, I'm replying to your mail:
"Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)"
in three seperate replies:
1. "Re: Proposed New Feature (SVNROOT)"
2. "Re: Proposed New Feature '.svnignore'"
3. "Re: Proposed New Feature 'rtag' (Revision Aliases)"
and I encourage people to continue discussion in each subthread seperately.
This is reply 2 of 3.
> .cvsignore
>
> I've tried the method described in the book and (1) it didn't work
and
> (2) I don't agree with it.
Please give much more detail. How didn't it work, and why don't you agree
with it.
> In the future I shall propose implementation of the other two features I
> would like. Here are my initial thoughts on those:
>
> .svnignore
>
> Similar to CVS except better (allow .svnignore to apply to directories):
> When the default 'svn status' command is given, for each directory first
> check for the presence of the file '.svnignore' and use the limited
regular
> expressions inside to check files and dirs that are unknown to svn (for
> "recursive" behavior, require an absolute or relative path to the file
> expression). Do not include those files in the resulting list.
How is this different to the svn:ignore property that we have already?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Martin Tomes <li...@tomes.org>.
Ben Collins-Sussman wrote:
> On Wed, 2004-03-17 at 10:50, Nuutti Kotivuori wrote:
>> * Usage must be easier than just using environment variables.
> This is exactly what I don't understand. Every time I hear a proposal
> for an SVNROOT feature, I ask myself, "why is this better than setting a
> normal environment variable? How will life be easier?"
>
> Can anyone explain?
No, I'm with you, SVNROOT just isn't needed.
--
Martin Tomes
echo 'Martin x Tomes at controls x eurotherm x co x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Tobias Ringstrom <to...@ringstrom.mine.nu>.
Ben Collins-Sussman wrote:
> This is exactly what I don't understand. Every time I hear a proposal
> for an SVNROOT feature, I ask myself, "why is this better than setting a
> normal environment variable? How will life be easier?"
>
> Can anyone explain?
I'm not advocating SVNROOT, but I can sure see why it would be a little
easier. The reason is that you set CVSROOT once (in your .bashrc
perhaps), and you don't have to type $CVSROOT every time. Having to
type $SVNROOT is more work. On the other hand, you don't have to call
it SVNROOT. The shorter the better...
/Tobias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-17 at 10:50, Nuutti Kotivuori wrote:
> * Usage must be easier than just using environment variables.
>
> Right now it is very easy to just say "export
> S=http://svn.collab.net/repos/svn" and then use it in operations,
> such as "svn co $S/trunk" or "svn cp $S/trunk $S/tags/1.0.0". Any
> SVNROOT proposal should be significantly easier than this to be
> worthwhile.
This is exactly what I don't understand. Every time I hear a proposal
for an SVNROOT feature, I ask myself, "why is this better than setting a
normal environment variable? How will life be easier?"
Can anyone explain?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Marcin Kasperski <Ma...@softax.com.pl>.
> > Also, many of the commands in Subversion behave *differently* when
> > invoked on URLs than when invoked on working copy paths. There is
> > quite often a need to invoke a command for the URL that corresponds to
> > the current working copy. And in many cases it is necessary to refer
> > to the root of the repository the working copy is in.
> >
> > So, just changing checkout and import not only makes them inconsistent
> > with all other commands taking URLs, but also does not really solve
> > the problem since the URLs are used all the time in other operations.
>
> I'd love to have something like $SVNROOT. But this reply is exactly
> right on the money. It needs to be made consistent with all the
> commands. I'm not sure there is a good way to do it.
What about syntax like
svn copy //some/file //other/file
(two slashes mean using default repository)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Ben Reser <be...@reser.org>.
On Wed, Mar 17, 2004 at 06:50:48PM +0200, Nuutti Kotivuori wrote:
> Kind of, but not exactly so. Every working copy knows the repository
> location for the path they are in - the working copies do not know the
> repository root they are inside. Eg. a normal checkout of subversion
> knows only that it is "http://svn.collab.net/repos/svn/trunk/" but
> does not know that "http://svn.collab.net/repos/svn/" is the root of
> the repository.
>
> Also, many of the commands in Subversion behave *differently* when
> invoked on URLs than when invoked on working copy paths. There is
> quite often a need to invoke a command for the URL that corresponds to
> the current working copy. And in many cases it is necessary to refer
> to the root of the repository the working copy is in.
>
> So, just changing checkout and import not only makes them inconsistent
> with all other commands taking URLs, but also does not really solve
> the problem since the URLs are used all the time in other operations.
I'd love to have something like $SVNROOT. But this reply is exactly
right on the money. It needs to be made consistent with all the
commands. I'm not sure there is a good way to do it.
In the end checkout and import are not commands I use a lot. However,
running commands like cp, mkdir, mv, etc... against a URL are something
I do from time to time. Far more often than a checkout or import. Any
change to support $SVNROOT isn't very valuable to me if it doesn't
handle these commands as well.
Perhaps a better option is simply an alias feature. I figure that could
go into the servers configuration like so:
[aliases]
svn = https://svn.collab.net/repos/svn
pers = https://svn.ben.reser.org
Then server configuration options could alias be set based on the alias
like we do with groups.
But further we could support "URLS" that looked like this:
svn:/trunk
where svn is the name of the alias.
Additionally, this could work with all clients, not just the command
line client. And if you use the alias and it is put in the working
copy's entry file and the root path to the repo changes you only have to
edit the config file, instead of running switch on multiple working
copies.
I've intentionally avoided using alias:// because it may create
namespace conflicts with other URL schemes supported by the tunneling
code and I was trying for something short and easy to type.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT)
Posted by Nuutti Kotivuori <na...@iki.fi>.
Max Bowsher wrote:
> TBrowder wrote:
>> The idea is to use SVNROOT (where defined) as it is used in CVS as
>> we commonly use it, to wit:
>>
>> 'cvs co module' (equates to 'svn co URL_to_repos/module')
>>
>> 'cvs import module [...and other args] (equates to 'svn import
>> URL_to_repos/module' without a local directory)
>>
>> To the best of my knowledge, svn and cvs default behaviors for
>> other commands are similar and don't need a reference to SVNROOT
>> because they both know the default repository location when the
>> user is in a directory with a working copy (WC).
Kind of, but not exactly so. Every working copy knows the repository
location for the path they are in - the working copies do not know the
repository root they are inside. Eg. a normal checkout of subversion
knows only that it is "http://svn.collab.net/repos/svn/trunk/" but
does not know that "http://svn.collab.net/repos/svn/" is the root of
the repository.
Also, many of the commands in Subversion behave *differently* when
invoked on URLs than when invoked on working copy paths. There is
quite often a need to invoke a command for the URL that corresponds to
the current working copy. And in many cases it is necessary to refer
to the root of the repository the working copy is in.
So, just changing checkout and import not only makes them inconsistent
with all other commands taking URLs, but also does not really solve
the problem since the URLs are used all the time in other operations.
>> My idea for the implementation of SVNROOT in svn is to intercept
>> the command line targets at the point just before they are checked
>> for errors and execution (in the files
>> './subversion/clients/cmdline/checkout-cmd.c' and
>> './subversion/clients/cmdline/import-cmd.c' ), check to see if
>> SVNROOT is defined, and make the appropriate substitutions in
>> targets (if they are not already in URL format), and pass the
>> arguments on as usual.
Actual implementation should be more or less trivial once design is
clear.
>> I believe the mod is innocuous, helpful to those who want such a
>> feature, and can be ignored by those who don't.
Granted, it does not change any of the ways Subversion can be used
today - but the new features make the interface inconsitent with the
other commands.
>> So ends my proposal for SVNROOT.
I will try to gather here invidual points, which I think a suggestion
should try to fulfill.
* SVNROOT functionality should be usable with all commands with URLs.
There are quite a few daily uses where one would need the
functionality, and being able to use it in one command, but not
another is wasteful.
* Usage of SVNROOT should be explicitly visible in the arguments.
Many commands in Subversion can take either URLs or WC paths as
arguments - for example "svn cp" which takes two arguments,
either which can be an URL or a WC path. To keep the interface
consistent, it should be possible to determine directly from an
argument whether it is an URL or not.
* Usage must be easier than just using environment variables.
Right now it is very easy to just say "export
S=http://svn.collab.net/repos/svn" and then use it in operations,
such as "svn co $S/trunk" or "svn cp $S/trunk $S/tags/1.0.0". Any
SVNROOT proposal should be significantly easier than this to be
worthwhile.
As an advanced point, I think there are two different functionalities
required. First of all the ability to refer to a global repository
root anywhere, regardless of current working copy - this would be the
SVNROOT functionality. And secondly to be able to refer to the
repository path that is in the current working copy - this would be
new functionality more or less specific to Subversion.
A note on filenames:
Currently, Subversion separates paths from URLs by looking for
"(schema)://", where schema can be anything which does not contain a
colon (:) or a slash (/). Any added modifications which should be
interpreted as URLs should hopefully be such, that nobody is likely to
have anything named like that in their repositories or working copies.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Re: Proposed New Feature (SVNROOT)
Posted by Tom Browder <to...@fwb.asi.srs.com>.
-----Original Message-----
From: Max Bowsher [mailto:maxb@ukf.net]
Sent: Wednesday, March 17, 2004 8:08 AM
Subject: [work] Re: Proposed New Feature (SVNROOT)
Max, thanks for your comments:
> It is good idea to keep email threads to a single concept. It makes the
>discussion far easier to follow.
Will do.
> My disagreement with a SVNROOT env-var is that if you do work on more than
> one repository, you end up having to remember what the env-var is
> currently set to,
echo $SVNROOT
> and most of the time end up overriding it on the command line anyway.
That's OK, too (no change from current usage).
> Also, checkout and import are rarely used operations (for me - do you use
> them regularly in your pattern of work?)
Yes, and usually in the same repository.
> and adding complexity to slightly shorten these commands seems like
> unnecessary code.
That's what programs are for: ease the user's job.
> Any discussion of command line simplification methods should include "svn
> switch" and "svn merge" - both of which could benefit in usability from a
> way to implicitly refer to the root of the repository of the working copy
> they are running in.
That bolsters the argument in favor of such a feature.
Tom Browder
Max.
---------------------------------------------------------------------
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
Re: Proposed New Feature (SVNROOT)
Posted by Max Bowsher <ma...@ukf.net>.
TBrowder wrote:
> I appreciate all the comments, and have no defense except I read the
> developer section of the book as well as HACKING and obviously didn't read
> them thoroughly enough. I will make the corrections suggested and
resubmit.
> (And Julian, thanks for your kind words.)
>
> However, before I resubmit the patch, I'll discuss my proposal in more
detail.
>
> Sometime last year (on the users list) I asked about three features we use
> heavily with CVS:
It is good idea to keep email threads to a single concept. It makes the
discussion far easier to follow.
Accordingly, I'm replying to your mail:
"Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)"
in three seperate replies:
1. "Re: Proposed New Feature (SVNROOT)"
2. "Re: Proposed New Feature '.svnignore'"
3. "Re: Proposed New Feature 'rtag' (Revision Aliases)"
and I encourage people to continue discussion in each subthread seperately.
This is reply 1 of 3.
> CVSROOT
>
> Allows an administrator an easy way to point to the repository.
Allows
> users a default location (svn URL) for their primary repository. I'm not
a
> touch typist and use aliases a lot. I can easily switch repositories with
a
> two- or three-character alias (under tcsh).
...
> Then, in the last few days, I put together the first of my proposals
> (SVNROOT):
>
> The idea is to use SVNROOT (where defined) as it is used in CVS as we
> commonly use it, to wit:
>
> 'cvs co module' (equates to 'svn co URL_to_repos/module')
>
> 'cvs import module [...and other args] (equates to 'svn import
> URL_to_repos/module' without a local directory)
>
> To the best of my knowledge, svn and cvs default behaviors for other
commands
> are similar and don't need a reference to SVNROOT because they both know
the
> default repository location when the user is in a directory with a working
> copy (WC).
>
> My idea for the implementation of SVNROOT in svn is to intercept the
command
> line targets at the point just before they are checked for errors and
> execution (in the files './subversion/clients/cmdline/checkout-cmd.c' and
> './subversion/clients/cmdline/import-cmd.c' ), check to see if SVNROOT is
> defined, and make the appropriate substitutions in targets (if they are
not
> already in URL format), and pass the arguments on as usual.
>
> I believe the mod is innocuous, helpful to those who want such a feature,
and
> can be ignored by those who don't.
>
> So ends my proposal for SVNROOT.
It's true that feature could simply be ignored by those people who didn't
want to use it.
My disagreement with a SVNROOT env-var is that if you do work on more than
one repository, you end up having to remember what the env-var is currently
set to, and most of the time end up overriding it on the command line
anyway.
Also, checkout and import are rarely used operations (for me - do you use
them regularly in your pattern of work?), and adding complexity to slightly
shorten these commands seems like unnecessary code.
Any discussion of command line simplification methods should include "svn
switch" and "svn merge" - both of which could benefit in usability from a
way to implicitly refer to the root of the repository of the working copy
they are running in.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature 'rtag' (Revision Aliases)
Posted by Max Bowsher <ma...@ukf.net>.
TBrowder wrote:
> I appreciate all the comments, and have no defense except I read the
> developer section of the book as well as HACKING and obviously didn't read
> them thoroughly enough. I will make the corrections suggested and
resubmit.
> (And Julian, thanks for your kind words.)
>
> However, before I resubmit the patch, I'll discuss my proposal in more
detail.
>
> Sometime last year (on the users list) I asked about three features we use
> heavily with CVS:
It is good idea to keep email threads to a single concept. It makes the
discussion far easier to follow.
Accordingly, I'm replying to your mail:
"Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)"
in three seperate replies:
1. "Re: Proposed New Feature (SVNROOT)"
2. "Re: Proposed New Feature '.svnignore'"
3. "Re: Proposed New Feature 'rtag' (Revision Aliases)"
and I encourage people to continue discussion in each subthread seperately.
This is reply 3 of 3.
> rtag (and the command 'cvs history -T')
>
> Allows a quick glance at milestones of a project without cluttering
up
> the repository tree with changeable tags. Not changeable by the user.
> Output of 'cvs history -T' is guaranteed to be in reverse chronological
> order.
> In the future I shall propose implementation of the other two features I
> would like. Here are my initial thoughts on those:
> rtag
>
> The best idea I can come up with is to add the capability for an alias for
a
> revision (but, better than CVS, with a larger allowable character set) and
it
> would appear (if defined) in the log listing. A new alias may also be
added
> at a later date. I think it should not be changeable (except for
additions)
> by anyone except the administrator. The alias should be able to be used
in
> any svn command that uses a revision number or date. The log listing
command
> should have a switch to avoid showing entries without a revision alias.
That kind of gives subversion 2 types of tags - a recipe for confusion. I
think it would be better to tune the log reporting and clients to make use
of the existing method of tagging in subversion in ways that better suit
your needs.
For example, svn log could show copy sources, thereby effectively showing
that certain revisions are tagged.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)
Posted by Nicolás Lichtmaier <jn...@synapsis-sa.com.ar>.
>> rtag (and the command 'cvs history -T')
>>
>> Allows a quick glance at milestones of a project without
>>cluttering up the repository tree with changeable tags. Not
>>changeable by the user. Output of 'cvs history -T' is guaranteed to
>>be in reverse chronological order.
>>
>>
>
>What makes you think that CVS tags are not changeable by the user? As
>far as I know, there's nothing stopping a CVS user from moving a tag.
>
>SVN's decision to make branches and tags part of the visible tree has
>both positive and negative consequences, most of which aren't terribly
>important. Polluting the design by adding a second kind of tag would
>let users choose which set of positives and negatives they want, but
>only at the expense of making Subversion a more complicated and
>harder-to-learn system. I think we should try to remain simple unless
>we discover strong evidence that we made the wrong call.
>
>
I think it wouldn't be to pollute subversion to add the concept of
moveable revision aliases, I would not call them tags to avoid
confusion. It would be useful to mark what has already been merged to
the trunk (the repeated merging problem) without having to scan the logs
as said in the book.
--
Nicolás Lichtmaier.-
Synapsis Argentina
+54(11)4314-3000 (int. 231)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)
Posted by Martin Tomes <li...@tomes.org>.
Marcin Kasperski wrote:
>>(Pros of SVN tags: the creation of a tag is a versioned event;...
> (b) maybe more subversion way - whenever I svn copy something,
> add log entry to the copy source (best if special so it can be
> easily distinguished with svn log switches). It will also help
> keep track of branching or just find out what have been copied
> and where.
A perl program which lists copies within a subtree of the repositories
is attached. It should do what you require:
$ ./findcopies.pl http://svn.eurotherm.co.uk:81/svn/randd/itools /itools
Rev. From->To
5 /itools/trunk:4->/itools/tags/5.00
6 /itools/trunk:5->/itools/branches/5.xx
8 /itools/branches/5.xx:7->/itools/tags/5.50
--
Martin Tomes
echo 'Martin x Tomes at controls x eurotherm x co x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision
Aliases)
Posted by Martin Tomes <li...@tomes.org>.
Max Bowsher wrote:
> Marcin Kasperski wrote:
>
>>>(Pros of SVN tags: the creation of a tag is a versioned event;
>>
>>In my opinion there is a desperate need for the feature which
>>will enable me to run svn log [some switch] within the working
>>dir of some component and get the list of tags created on this
>>component.
>
> Option (c): Like option (b), but work not by adding extra log entries, but
> by reporting copy sources in the svn log output.
I had a perl program which very nearly does what you are asking so I
hacked it about a bit and it is attached. Put the repository url and
the path within the repository to match and it will list copies.
Example output:
$ ./findcopies.pl http://svn.eurotherm.co.uk:81/svn/randd/itools /itools
Rev. From->To
5 /itools/trunk:4->/itools/tags/5.00
6 /itools/trunk:5->/itools/branches/5.xx
8 /itools/branches/5.xx:7->/itools/tags/5.50
You should be able to hack this to give the output you require. You
will need to put a valid user/password for your repository into the code.
--
Martin Tomes
echo 'Martin x Tomes at controls x eurotherm x co x uk'\
| sed -e 's/ x /\./g' -e 's/ at /@/'
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision Aliases)
Posted by Max Bowsher <ma...@ukf.net>.
Marcin Kasperski wrote:
>> (Pros of SVN tags: the creation of a tag is a versioned event;
>> you can manage the set of visible tags without permanently
>> destroying information; a single concept covers copies,
>> branching, and tag operations. Cons of SVN tags: you can't
>> get a comprehensive list of all the tags ever created without
>> a complicated query; they create a multiplying effect if
>> people check out the root of your tree; an extra mechanism is
>> required to prevent users from editing the contents of a tag;
>> folding copying and branching into a single concept may lose
>> information.)
>
> In my opinion there is a desperate need for the feature which
> will enable me to run svn log [some switch] within the working
> dir of some component and get the list of tags created on this
> component.
>
> It can be solved in two ways:
> (a) cvs way - add the more cvs-like tag or alias concept and use
> it
> (b) maybe more subversion way - whenever I svn copy something,
> add log entry to the copy source (best if special so it can be
> easily distinguished with svn log switches). It will also help
> keep track of branching or just find out what have been copied
> and where.
Option (c): Like option (b), but work not by adding extra log entries, but
by reporting copy sources in the svn log output.
Would you like to file a feature request in IssueZilla, to ensure this
doesn't get forgotten?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision Aliases)
Posted by Marcin Kasperski <Ma...@softax.com.pl>.
> (Pros of SVN tags: the creation of a tag is a versioned event;
> you can manage the set of visible tags without permanently
> destroying information; a single concept covers copies,
> branching, and tag operations. Cons of SVN tags: you can't
> get a comprehensive list of all the tags ever created without
> a complicated query; they create a multiplying effect if
> people check out the root of your tree; an extra mechanism is
> required to prevent users from editing the contents of a tag;
> folding copying and branching into a single concept may lose
> information.)
In my opinion there is a desperate need for the feature which
will enable me to run svn log [some switch] within the working
dir of some component and get the list of tags created on this
component.
It can be solved in two ways:
(a) cvs way - add the more cvs-like tag or alias concept and use
it
(b) maybe more subversion way - whenever I svn copy something,
add log entry to the copy source (best if special so it can be
easily distinguished with svn log switches). It will also help
keep track of branching or just find out what have been copied
and where.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag' (Revision Aliases)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Greg Hudson <gh...@MIT.EDU> writes:
> On Wed, 2004-03-17 at 06:53, TBrowder wrote:
> [About SVNROOT]
> > Allows an administrator an easy way to point to the repository.
> > Allows users a default location (svn URL) for their primary
> > repository. I'm not a touch typist and use aliases a lot. I can
> > easily switch repositories with a two- or three-character alias (under
> > tcsh).
>
> Similarly, though, can't you just set two- or three-character shell
> variables for the repositories you use frequently, and then do "svn co
> $rep/pathname dirname"?
>
> I don't think that approach works so well under Windows, but neither do
> your shell aliases.
Works fine.
C:\Temp>set SVNREPOS=http://svn.collab.net/repos/svn/trunk
C:\Temp>svn co %SVNREPOS%/subversion/tests/libsvn_fs
A libsvn_fs\run-fs-tests.py
A libsvn_fs\key-test.c
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag'
(Revision Aliases)
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2004-03-17 at 06:53, TBrowder wrote:
[About SVNROOT]
> Allows an administrator an easy way to point to the repository.
> Allows users a default location (svn URL) for their primary
> repository. I'm not a touch typist and use aliases a lot. I can
> easily switch repositories with a two- or three-character alias (under
> tcsh).
Similarly, though, can't you just set two- or three-character shell
variables for the repositories you use frequently, and then do "svn co
$rep/pathname dirname"?
I don't think that approach works so well under Windows, but neither do
your shell aliases.
> .cvsignore
>
> I've tried the method described in the book and (1) it didn't
> work and (2) I don't agree with it.
.cvsignore maps very closely onto the svn:ignores property; I don't see
any reason why we would want two ways of doing the same thing.
> rtag (and the command 'cvs history -T')
>
> Allows a quick glance at milestones of a project without
> cluttering up the repository tree with changeable tags. Not
> changeable by the user. Output of 'cvs history -T' is guaranteed to
> be in reverse chronological order.
What makes you think that CVS tags are not changeable by the user? As
far as I know, there's nothing stopping a CVS user from moving a tag.
SVN's decision to make branches and tags part of the visible tree has
both positive and negative consequences, most of which aren't terribly
important. Polluting the design by adding a second kind of tag would
let users choose which set of positives and negatives they want, but
only at the expense of making Subversion a more complicated and
harder-to-learn system. I think we should try to remain simple unless
we discover strong evidence that we made the wrong call.
(Pros of SVN tags: the creation of a tag is a versioned event; you can
manage the set of visible tags without permanently destroying
information; a single concept covers copies, branching, and tag
operations. Cons of SVN tags: you can't get a comprehensive list of all
the tags ever created without a complicated query; they create a
multiplying effect if people check out the root of your tree; an extra
mechanism is required to prevent users from editing the contents of a
tag; folding copying and branching into a single concept may lose
information.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org