You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nahuel Greco <ng...@axonsis.com.ar> on 2003/08/08 14:31:31 UTC
Subversion wishes / proposed enhacements
I have two wishes for subversion (I don't know if this mail address is the
correct way to report them).
1- Because svn has a sane way to handle binary files, we are using it very
intensively, but there is a problem, the size of the repository grows very
fast. A nice addition can be the posibility of set, with a property, the
maximum number of revisions too keep in the repository by file. Or a way to
move the old revisions to other archive and backup them, keeping only the
N new ones.
2- A file has intrinsically a versin number. That is, when you edit a file,
and you commit it, you have a new version of the file, but SVN only keeps
their global revision number. It will be nice if you can retrive a file
by their local revision, or use it in replaceable keywords. This is
needed for some uses and in some cases is more intuitive.
Saludos,
Nahuel Greco.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by cm...@collab.net.
Nahuel Greco <ng...@axonsis.com.ar> writes:
> 1- Because svn has a sane way to handle binary files, we are using it very
> intensively, but there is a problem, the size of the repository grows very
> fast. A nice addition can be the posibility of set, with a property, the
> maximum number of revisions too keep in the repository by file. Or a way to
> move the old revisions to other archive and backup them, keeping only the
> N new ones.
Oh! What *you* want is Subversion from about two years ago, where one
of Ben's bugs caused us only to keep the HEAD version of each file. I
wanted to just release the product as OneVersion 1.0 at that point,
but I was overruled...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Vincent Lefevre <vi...@vinc17.org>.
On Mon, Aug 11, 2003 at 13:16:01 -0400, mark benedetto king wrote:
> On Mon, Aug 11, 2003 at 10:13:35AM -0500, kfogel@collab.net wrote:
> > We don't have a keyword like $ChangeCount$ yet. (Maybe Post-1.0?)
>
> Also, how would merging from branch to the trunk affect $ChangeCount$?
I think that a merge would be only a change (so, it should add 1 to
$ChangeCount$). I don't see any problem with that.
--
Vincent Lefèvre <vi...@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des
Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by mark benedetto king <mb...@lowlatency.com>.
On Mon, Aug 11, 2003 at 10:13:35AM -0500, kfogel@collab.net wrote:
> Nahuel Greco <ng...@axonsis.com.ar> writes:
> > Sure, it doesn't map to "amount of work" logically, but intuitively/fuzzyly.
> > Also, this isn't against the subversion global revision concept, I only
> > ask for allowing the use of a valid revision information, the number of
> > changes of a file.
>
> We don't have a keyword like $ChangeCount$ yet. (Maybe Post-1.0?)
>
Also, how would merging from branch to the trunk affect $ChangeCount$?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by kf...@collab.net.
Nahuel Greco <ng...@axonsis.com.ar> writes:
> Sure, it doesn't map to "amount of work" logically, but intuitively/fuzzyly.
> Also, this isn't against the subversion global revision concept, I only
> ask for allowing the use of a valid revision information, the number of
> changes of a file.
We don't have a keyword like $ChangeCount$ yet. (Maybe Post-1.0?)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Nahuel Greco <ng...@axonsis.com.ar>.
On Mon, 11 Aug 2003 11:17:32 -0400
Garrett Rooney <ro...@electricjellyfish.net> wrote:
> Well, that's not what you said ;-)
>
> You said you wanted something that increases only when the file changes.
> This does increase only when the file changes, it just increases by an
> indeterminate amount each time ;-)
>
Ok, I mean increase by one, that information was lost in my head when I
wrote the previous post :)
> Seriously, using the number of times a file has changed as a reflection
> of anything other than the number of times it has changed is a bad idea.
> A high number of changes doesn't really map to "amount of work", or
> anything meaningful in all cases.
>
Sure, it doesn't map to "amount of work" logically, but intuitively/fuzzyly.
Also, this isn't against the subversion global revision concept, I only
ask for allowing the use of a valid revision information, the number of
changes of a file.
Saludos,
Nahuel Greco.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Nahuel Greco wrote:
> On Mon, 11 Aug 2003 11:08:26 -0400
> Garrett Rooney <ro...@electricjellyfish.net> wrote:
>
>
>>>Is important to me to have a way to reference (and to have replace keywords)
>>>a file by a number that increases only when that file is changed.
>>
>>You already have that. The $Rev$ (aka $LastChangedRev$) keyword will
>>expand to the revision in which the file last changed. If the file
>>isn't modified in a commit, this number will not change.
>
>
> No, I want to have a $Rev$ incremented by one for each change. So, for example,
> if I see a file with $LocalRev 3$ and other with $LocalRev 444$ i will know
> which one has more work. This was discussed on IRC a month ago.
Well, that's not what you said ;-)
You said you wanted something that increases only when the file changes.
This does increase only when the file changes, it just increases by an
indeterminate amount each time ;-)
Seriously, using the number of times a file has changed as a reflection
of anything other than the number of times it has changed is a bad idea.
A high number of changes doesn't really map to "amount of work", or
anything meaningful in all cases.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion enhacement Req: "--exclude" option for checkout, update,
add
Posted by John Peacock <jp...@rowman.com>.
Jack Repenning wrote:
>
> Yes, I can see significant value in this as well (e.g., in a bridge
> script I maintain).
You can also view the long discussion I started last month here:
http://www.contactor.se/~dast/svn/archive-2003-07/1969.shtml
that would neatly be solved by the ability to exclude a subtree during a checkout...
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: Subversion enhacement Req: "--exclude" option for checkout,
update, add
Posted by Jack Repenning <jr...@collab.net>.
At 1:03 PM -0400 8/11/03, Matt Blais wrote:
>It would be useful to be able to exclude specific entries or patterns
>from 'checkout' and 'add'.
Yes, I can see significant value in this as well (e.g., in a bridge
script I maintain). And it's a fairly common request in the world at
large (witness: ClearCase recently added support for this, by the
dodge that "update" doesn't update a file if unexists ... rather a
pain, that approach, since healing an accidental deletion requires
special efforts ... think they landed on the wrong side of "common
things should be simple, uncommon things should be possible" ... but
anyway, this shows the demand).
Hmmm ... this would depend upon the support for "defined but missing"
files we've tossed around, wouldn't it? E.g., if you "svn up -r1
somefile," then somefile disappears (because it didn't exist in r1),
but you can't get it back (because there's some turmoil over finding
it to say "give it back" about). I think the status of that was: at
first we thought it was the same as the existing idea of "deleted,"
but it really isn't. Maybe this RFE has at least given us a name for
the new state -- "Excluded".
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Subversion enhacement Req: "--exclude" option for checkout, update, add
Posted by Matt Blais <mb...@yummage.com>.
It would be useful to be able to exclude specific entries or patterns
from 'checkout' and 'add'.
E.g., I want to checkout a dir that contains a "./bin" subdir, but I
want to exclude ./bin from the checkout.
Specifying a PATTERN to exclude recursively would also be useful. E.g.,
--exclude *.jpg;*.gif
How would this affect updates? Ideally subversion would remember what
--exclude options were used for a checkout, and automatically apply the
same exclusions to subsequent updates on the dir (i.e., exclude is
"sticky").
Also needed would be a new 'update' flag to "create all missing
entries", which would have the effect of causing subversion to "forget"
the excludes that were originally used to checkout the dir.
I'm sure there are a few more commands that would be impacted.
--Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Nahuel Greco <ng...@axonsis.com.ar>.
On Mon, 11 Aug 2003 11:08:26 -0400
Garrett Rooney <ro...@electricjellyfish.net> wrote:
> > Is important to me to have a way to reference (and to have replace keywords)
> > a file by a number that increases only when that file is changed.
>
> You already have that. The $Rev$ (aka $LastChangedRev$) keyword will
> expand to the revision in which the file last changed. If the file
> isn't modified in a commit, this number will not change.
No, I want to have a $Rev$ incremented by one for each change. So, for example,
if I see a file with $LocalRev 3$ and other with $LocalRev 444$ i will know
which one has more work. This was discussed on IRC a month ago.
Saludos,
Nahuel Greco.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
Nahuel Greco wrote:
> On Sat, 9 Aug 2003 14:50:03 -0700
> Jack Repenning <jr...@collab.net> wrote:
>
>
>>Isn't the Subversion "change revision" what you want here (the global
>>revision where this file version was created)? Or is it important to
>>you that the change number increase by only one number for each
>>change?
>
>
> Is important to me to have a way to reference (and to have replace keywords)
> a file by a number that increases only when that file is changed.
You already have that. The $Rev$ (aka $LastChangedRev$) keyword will
expand to the revision in which the file last changed. If the file
isn't modified in a commit, this number will not change.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Nahuel Greco <ng...@axonsis.com.ar>.
On Sat, 9 Aug 2003 14:50:03 -0700
Jack Repenning <jr...@collab.net> wrote:
> Isn't the Subversion "change revision" what you want here (the global
> revision where this file version was created)? Or is it important to
> you that the change number increase by only one number for each
> change?
Is important to me to have a way to reference (and to have replace keywords)
a file by a number that increases only when that file is changed.
Saludos,
Nahuel Greco.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion wishes / proposed enhacements
Posted by Jack Repenning <jr...@collab.net>.
At 11:31 AM -0300 8/8/03, Nahuel Greco wrote:
>
>2- A file has intrinsically a versin number. That is, when you edit a file,
>and you commit it, you have a new version of the file, but SVN only keeps
>their global revision number. It will be nice if you can retrive a file
>by their local revision, or use it in replaceable keywords. This is
>needed for some uses and in some cases is more intuitive.
>
Isn't the Subversion "change revision" what you want here (the global
revision where this file version was created)? Or is it important to
you that the change number increase by only one number for each
change?
--
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org