You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/03/17 16:47:44 UTC
Re: Proposed New Feature (SVNROOT), '.svnignore', and 'rtag'
(Revision Aliases)
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
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