You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mad Scientist <ma...@gmail.com> on 2008/03/12 05:29:08 UTC
Unversioned files held by repo
Hi, I am looking to submit a feature request for unversioned files
stored in the repository along with normal versioned files. This could
be beneficial for files such as project licenses which apply to all
revisions or the latest generated files for people who do not want or
are unable to compile/build the files themselves. It keeps could also
keep the generated files in an easy to remove format when they become
out dated or space becomes an issue. I was thinking maybe these files
could be stored internally ( just a guess/suggestion ) at revision 0 or
-1 and override any versioned files.( could allow misplaced files to be
'removed' as a quick patch until the repository is fixed, confidential
data on a public repository for instance )
Thanks in advance for any additional constructive comments.
~Mad Scientist
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 12, 2008, at 00:29, Mad Scientist wrote:
> Hi, I am looking to submit a feature request for unversioned files
> stored in the repository along with normal versioned files. This
> could be beneficial for files such as project licenses which apply
> to all revisions or the latest generated files for people who do
> not want or are unable to compile/build the files themselves. It
> keeps could also keep the generated files in an easy to remove
> format when they become out dated or space becomes an issue. I was
> thinking maybe these files could be stored internally ( just a
> guess/suggestion ) at revision 0 or -1 and override any versioned
> files.( could allow misplaced files to be 'removed' as a quick
> patch until the repository is fixed, confidential data on a public
> repository for instance )
>
> Thanks in advance for any additional constructive comments.
This has been suggested before, and I don't think it's going to be
implemented in Subversion. It would be a big task because it asks for
several things not currently in Subversion, and in the end you'd have
something that's very similar to a file server, so the answer is to
use an existing file server.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Wednesday, March 12, 2008 12:34 PM
> To: Paul Koning
> Cc: madscientist343@gmail.com; andy.levy@gmail.com;
> users@subversion.tigris.org
> Subject: Re: Unversioned files held by repo
>
>
> Except that preserving all history of everything forever is
impractical
> and at some point becomes impossible and will thus cause you to lose
it
> all. So it is not as evil as you might think to be selective about
> what
> you keep. And it is a very practical choice to not want to duplicate
> your access/distribution infrastructure and user training to also
> manage
> content that doesn't need to be archived forever. The only reasonable
> approach I can see to this with a current subversion setup is to use
> http access to permit using multiple repositories under what looks
like
> a single url, then periodically purge and reconstruct the repositories
> that contain disposable contents. You can also provide http access
> through viewvc as a simple way to grab the current version. And it is
> still an administrative decision regarding when/what to purge,
> requiring
> file level access to the repository.
>
Try looking at a continuous integration tool to manage build objects.
Based on what I've heard in passing when I was only half paying
attention, I think Hudson saves off builds to make future builds faster.
Although you might need to do something like give each developer their
own Hudson build project so they can build independently. End result is
that Hudson manages the build objects instead of subversion or the
developer. (Hudson works with subversion.)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
RE: Unversioned files held by repo
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Wednesday, March 12, 2008 2:55 PM
> To: Reedick, Andrew
> Cc: users@subversion.tigris.org
> Subject: Re: Unversioned files held by repo
>
>
> But consider a likely alternative, where you run the repository out of
> space because you can't delete just to maintain unwanted disposable
> and/or reproducible content. Or on the opposite site you have people
> who avoid committing things because of the side effects that can't be
> undone.
>
> > It breaks build repeatability.
>
> A likely scenario is that the items in question are build targets, not
> dependencies, but you'd like them stored temporarily or for others to
> be
> able to access them without having to build their own.
So you want something like ClearCase's wink-in capability? Do a build
in workspace/view1. Someone kicks off a similar build in
workspace/view2. Instead of rebuilding each and every derived object
(build object), ClearCase will grab the object from view1 and pull it
into view2. At which point the build object is stored on the ClearCase
server for easier sharing. IIRC.
ClearCase will also go through the extra effort of comparing version
numbers when 'winking in' derived objects, since make programs can be
mislead by how version control systems play with file timestamps.
Plan C would be to build revision 100. Tar up revision 100's build
output and put it on the network.
User Bravo checkouts 100. Bravo then untars the 100.tar into his
workspace. Bravo then probably needs to touch all the files (from the
tar) so that make isn't confused. Bravo then 'svn updates' to revision
110 and kicks off an incremental build.
Plan C.1 It might be a good idea to tweak the build scripts to put the
build output in an entirely separate directory. That would make the
file/dir slinging easier.
Plan D. Instead of a tar, just put the full build output on a file
server. Tweak the build scripts to look there before deciding whether
to rebuild a particular object file or not. At one company I worked
for, a local build would look at the main network dir, the secondary
network dir, and finally the local dir before deciding whether to build
a piece of code. No idea what those makefiles looked like.
Plan E Avoid the whole issue by getting a faster build machine, or setup
distributed/parallel builds. =)
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Paul Koning wrote:
>
> Les> A likely scenario is that the items in question are build
> Les> targets, not dependencies, but you'd like them stored
> Les> temporarily or for others to be able to access them without
> Les> having to build their own.
>
> Ok, so the real issue is that you want to use a SOURCE control system
> to be an arbitrary database for arbitrary stuff, and Subversion
> doesn't do that because it's a source control system.
A better description is that I would like to teach users that the right
way to handle anything that might need saving for later retrieval is to
commit it to subversion and the right way to get the current version of
something is to update their checked out copy.
> I think maybe you're looking for an anvil and complaining because the
> hammer you have doesn't make a good anvil... :-)
Maybe, but it's not a really bad anvil either, just awkward sometimes.
> Personally, I would much prefer Subversion to concentrate on being an
> efficient and reliable source control system, and not get distracted
> by completely unrelated requirements that aren't just irrelevant, but
> in fact harmless, to its mission.
I think of it as a VERSION control system - and just think it would be
nice to be able to manage the versions it maintains with a handier tool
than dump/filter/load. I'm not asking for a new capability here, just a
more convenient one.
> By the way, have you tried doing what you want the regular way? Given
> that Subversion (unlike CVS) does binary deltas, storing build output
> -- even though that's not what Subversion is intended for -- may in
> fact work just fine. Especially with today's big disk drives...
I agree that it is very good - and have dumped in decade-old CVS
histories without bothering to sort out all the parts we don't need now,
but I haven't found a disk yet that users can't fill if you tell them to
save everything. And the disk itself is somewhat irrelevant compared to
the backup media and mechanism to support it. I'm looking at this from
the perspective of already having 10+ years of history accumulated and
knowing that a lot is already useless. How long do you 'store
everything forever' proponents think of as 'forever'?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Les" == Les Mikesell <le...@gmail.com> writes:
Les> Reedick, Andrew wrote:
>>
>>> Except that preserving all history of everything forever is
>> impractical
>>> and at some point becomes impossible and will thus cause you to
>>> lose
>> it
>>> all. So it is not as evil as you might think to be selective
>>> about what you keep.
>>
>>
>> No, it is Evil as per FDA standards.
Les> But consider a likely alternative, where you run the repository
Les> out of space because you can't delete just to maintain unwanted
Les> disposable and/or reproducible content. Or on the opposite site
Les> you have people who avoid committing things because of the side
Les> effects that can't be undone.
>> It breaks build repeatability.
Les> A likely scenario is that the items in question are build
Les> targets, not dependencies, but you'd like them stored
Les> temporarily or for others to be able to access them without
Les> having to build their own.
Ok, so the real issue is that you want to use a SOURCE control system
to be an arbitrary database for arbitrary stuff, and Subversion
doesn't do that because it's a source control system.
I think maybe you're looking for an anvil and complaining because the
hammer you have doesn't make a good anvil... :-)
Personally, I would much prefer Subversion to concentrate on being an
efficient and reliable source control system, and not get distracted
by completely unrelated requirements that aren't just irrelevant, but
in fact harmless, to its mission.
By the way, have you tried doing what you want the regular way? Given
that Subversion (unlike CVS) does binary deltas, storing build output
-- even though that's not what Subversion is intended for -- may in
fact work just fine. Especially with today's big disk drives...
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Reedick, Andrew wrote:
>
>> Except that preserving all history of everything forever is
> impractical
>> and at some point becomes impossible and will thus cause you to lose
> it
>> all. So it is not as evil as you might think to be selective about
>> what
>> you keep.
>
>
> No, it is Evil as per FDA standards.
But consider a likely alternative, where you run the repository out of
space because you can't delete just to maintain unwanted disposable
and/or reproducible content. Or on the opposite site you have people
who avoid committing things because of the side effects that can't be
undone.
> It breaks build repeatability.
A likely scenario is that the items in question are build targets, not
dependencies, but you'd like them stored temporarily or for others to be
able to access them without having to build their own.
> Specifically, how would you roll back or otherwise deploy a previous
> build/deployment if the disposable files are not being tracked?
The same way you'd do it in the current situation where you never commit
those files at all.
> Plan B would be to check the disposable files into a separate disposable
> repository (or put them on a file server.) Users would check out from
> the main repository and then run a script to pull the data from the
> disposable repository/file server into their workspace. The disposable
> repository could be wiped as needed.
That's sort-of workable, but only if they can live in separate directories.
> It's the best of both worlds, but you would need to write wrapper
> scripts for 'svn co' and 'svn update' to make it easy for people to pull
> the disposable files in.
Having to write scripts for each file doesn't sound all that easy to me.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by "Reedick, Andrew" <jr...@ATT.COM>.
> -----Original Message-----
> From: Les Mikesell [mailto:lesmikesell@gmail.com]
> Sent: Wednesday, March 12, 2008 12:34 PM
> To: Paul Koning
> Cc: madscientist343@gmail.com; andy.levy@gmail.com;
> users@subversion.tigris.org
> Subject: Re: Unversioned files held by repo
>
> >
> > Then again, it strikes me that what you're proposing is positively
> > evil -- something that goes directly against what any source control
> > system should do. The whole point of source control is to be able
to
> > see history. The mechanism you describe specifically aims to
destroy
> > history. This is bad. Subversion must not consider ever doing such
> a
> > thing.
>
> Except that preserving all history of everything forever is
impractical
> and at some point becomes impossible and will thus cause you to lose
it
> all. So it is not as evil as you might think to be selective about
> what
> you keep.
No, it is Evil as per FDA standards. It breaks build repeatability.
Specifically, how would you roll back or otherwise deploy a previous
build/deployment if the disposable files are not being tracked?
Plan B would be to check the disposable files into a separate disposable
repository (or put them on a file server.) Users would check out from
the main repository and then run a script to pull the data from the
disposable repository/file server into their workspace. The disposable
repository could be wiped as needed.
It's the best of both worlds, but you would need to write wrapper
scripts for 'svn co' and 'svn update' to make it easy for people to pull
the disposable files in.
Plan B.1 would be to attach unversioned revision properties to revision
1 of the archive. The user would run a script to pull in the unversioned
files listed in the revision property. If there are no limits to the
size of an unversioned revision property, you could in theory, attach
entire files as properties... Properties containing entire files would
make it easy for the script to update a workspace's disposable files.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA621
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Paul Koning wrote:
>> >> <ma...@gmail.com> wrote: > Hi, I am looking to submit a
> >> feature request for unversioned files > stored in the repository
> >> along with normal versioned files. This could > be beneficial for
> >> files such as project licenses which apply to all > revisions
> >>
> >> Why would these need to be unversioned but in the repository? Put
> >> them in normally, and if they never change, how is it different
> >> from keeping them in the repo, unversioned?
>
>
> Mad> The benefit would be when the files do need to be changed and
> Mad> applied to previous revisions ( eg a license that covers all
> Mad> files in the repository ) you are able to change them on every
> Mad> revision( from the view of a working copy ) instead of just
> Mad> changing the latest revision.
>
> You might be able to do this with externals.
>
> Then again, it strikes me that what you're proposing is positively
> evil -- something that goes directly against what any source control
> system should do. The whole point of source control is to be able to
> see history. The mechanism you describe specifically aims to destroy
> history. This is bad. Subversion must not consider ever doing such a
> thing.
Except that preserving all history of everything forever is impractical
and at some point becomes impossible and will thus cause you to lose it
all. So it is not as evil as you might think to be selective about what
you keep. And it is a very practical choice to not want to duplicate
your access/distribution infrastructure and user training to also manage
content that doesn't need to be archived forever. The only reasonable
approach I can see to this with a current subversion setup is to use
http access to permit using multiple repositories under what looks like
a single url, then periodically purge and reconstruct the repositories
that contain disposable contents. You can also provide http access
through viewvc as a simple way to grab the current version. And it is
still an administrative decision regarding when/what to purge, requiring
file level access to the repository.
This is just a special case of the need for a better administrative tool
to remove unwanted content.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Mad" == Mad Scientist <ma...@gmail.com> writes:
Mad> On Wed, Mar 12, 2008 at 6:23 AM, Andy Levy <an...@gmail.com>
Mad> wrote:
>> On Wed, Mar 12, 2008 at 1:29 AM, Mad Scientist
>> <ma...@gmail.com> wrote: > Hi, I am looking to submit a
>> feature request for unversioned files > stored in the repository
>> along with normal versioned files. This could > be beneficial for
>> files such as project licenses which apply to all > revisions
>>
>> Why would these need to be unversioned but in the repository? Put
>> them in normally, and if they never change, how is it different
>> from keeping them in the repo, unversioned?
Mad> The benefit would be when the files do need to be changed and
Mad> applied to previous revisions ( eg a license that covers all
Mad> files in the repository ) you are able to change them on every
Mad> revision( from the view of a working copy ) instead of just
Mad> changing the latest revision.
You might be able to do this with externals.
Then again, it strikes me that what you're proposing is positively
evil -- something that goes directly against what any source control
system should do. The whole point of source control is to be able to
see history. The mechanism you describe specifically aims to destroy
history. This is bad. Subversion must not consider ever doing such a
thing.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
>
>>> Subversion supports that model by not making more copies of a file
>>> than necessary: all revisions for which a file is the same share
>>> storage. So, for files which change infrequently, you shouldn't be
>>> hesitant to store them in your repository.
>> But... there are files that do change frequently and files where old
>> instances have no use at all - and it would still be nice to be able to
>> use subversions's access mechanisms to store and distribute them. And,
>> of course, it would be nice to have a reasonable way to undo accidental
>> commits of things that don't belong in the repository at all or can't
>> remain for legal or political correctness reasons.
>
> Nice, yes. But: it's not what Subversion is designed for nor will it
> ever be a goal for Subversion.
I think that's an impractical view, since being unable to manage
repository content in all of the commonly needed ways hinders any goals
you might otherwise have.
> If you want to simply distribute files,
> there are other solutions which may work equally well or better. So,
> don't be surprised you're seeing some resistance here.
Of course it is possible to implement a different mechanism to manage
and distribute every separate file and tune each perfectly to the nature
of each file type. But that seems like a bad idea compared to having
people learn to commit changes and update to get new versions.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/12/08, Les Mikesell <le...@gmail.com> wrote:
> Erik Huelsmann wrote:
> >
> > Subversion supports that model by not making more copies of a file
> > than necessary: all revisions for which a file is the same share
> > storage. So, for files which change infrequently, you shouldn't be
> > hesitant to store them in your repository.
>
> But... there are files that do change frequently and files where old
> instances have no use at all - and it would still be nice to be able to
> use subversions's access mechanisms to store and distribute them. And,
> of course, it would be nice to have a reasonable way to undo accidental
> commits of things that don't belong in the repository at all or can't
> remain for legal or political correctness reasons.
Nice, yes. But: it's not what Subversion is designed for nor will it
ever be a goal for Subversion. If you want to simply distribute files,
there are other solutions which may work equally well or better. So,
don't be surprised you're seeing some resistance here.
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Matt imMute Sickler wrote:
>
> Here is exactly another case where "unversioned files" would be the ruin
> of anyone using them. Suppose you build at r10, and add the binary to
> the tree. Then 10 revisions later, you build again. Now say _someone
> else_ wants to go back and run the program as existed in r10. THEY CANT
> because they will get the binary from r20!
How is that worse than not adding the binary at all?
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Mad Scientist wrote:
>
>
> On Wed, Mar 12, 2008 at 3:30 PM, Paul Koning <Paul_Koning@dell.com
> <ma...@dell.com>> wrote:
>
> >>>>> "Matt" == Matt imMute Sickler <immute@msk4.ath.cx
> <ma...@msk4.ath.cx>> writes:
>
> Matt> Subversion was designed not to lose history and does a damn
> Matt> good job of it. If anyone *really really* wants this
> Matt> functionality, ...
>
> I wouldn't go that far. At the very most, such a patch could be
> tolerated if and only if the "feature" defaults to disabled. But my
> preference is that any such patch shuold be rejected out of hand.
>
>
> I was thinking more it would be something where it gives you the option
> to commit files with a unversioned flag set( maybe svn:unversioned ). So
> it would definitely be opt in not opt out.
And I'd envision it as something that should require file level access
to the repository, since it is the moral equivalent of doing a
dump/filter/load. Or it should just hide the old versions until an
admin uses some command to purge them from the repository.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Mad Scientist <ma...@gmail.com>.
On Wed, Mar 12, 2008 at 3:30 PM, Paul Koning <Pa...@dell.com> wrote:
> >>>>> "Matt" == Matt imMute Sickler <im...@msk4.ath.cx> writes:
>
> Matt> Subversion was designed not to lose history and does a damn
> Matt> good job of it. If anyone *really really* wants this
> Matt> functionality, ...
>
> I wouldn't go that far. At the very most, such a patch could be
> tolerated if and only if the "feature" defaults to disabled. But my
> preference is that any such patch shuold be rejected out of hand.
>
> paul
I was thinking more it would be something where it gives you the option to
commit files with a unversioned flag set( maybe svn:unversioned ). So it
would definitely be opt in not opt out.
Re: Unversioned files held by repo
Posted by Paul Koning <Pa...@dell.com>.
>>>>> "Matt" == Matt imMute Sickler <im...@msk4.ath.cx> writes:
Matt> Subversion was designed not to lose history and does a damn
Matt> good job of it. If anyone *really really* wants this
Matt> functionality, ...
I wouldn't go that far. At the very most, such a patch could be
tolerated if and only if the "feature" defaults to disabled. But my
preference is that any such patch shuold be rejected out of hand.
paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Jared Hardy <ja...@gmail.com>.
+1 to the file "history depth = 1" feature, from this user. Good way
of simplifying the issue Mad Scientist! Being forced to keep the same
exact history properties on everything (i.e. history depth is always
infinity) is really annoying.
In case everyone else hasn't noticed, Perforce recently added a
history depth setting to their SCM, where you can define the maximum
history depth you want to keep around for any given file, or general
file type (i.e. mp4). This is really useful for keeping shallow
history of big files, compressed files, and/or even compiled files.
Some use cases might also find it is a better way to track externals,
in an atomic fashion. It allows the user/admin to keep better control
of their repository size, makes obliterate implementation trivial, and
allows *atomic tracking of all files*, not just "source" files.
It seems that at least one SCM has figured out that "designed not to
lose history" might be better extended to "designed not to lose
history, unless the user definitely WANTS it to". It sounds like
Mercurial is also working on overlay and history hole-punching
features, that accomplish the same goals. Isn't an obliterate command
also on SVN's roadmap? What about "selectively obliterate history"?
I've seen a lot of requests for this kind of feature -- stop giving
Mad Scientist such a hard time about it.
:) Jred
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Mad Scientist <ma...@gmail.com>.
On Wed, Mar 12, 2008 at 4:06 PM, Matt imMute Sickler <im...@msk4.ath.cx>
wrote:
> Mad Scientist wrote:
> [snip]
> > Though you could rename
> > the binary or put them each in a folder with the revision number to keep
> > them separate.
>
> And how is that any different than just versioning the binary using svn
> (except that its more awkward).
>
> You can remove the files when no longer need/wanted without having to do
even more steps to remove it from the repo files and rebuild everything.
Re: Unversioned files held by repo
Posted by Mad Scientist <ma...@gmail.com>.
> Here is exactly another case where "unversioned files" would be the ruin
> of anyone using them. Suppose you build at r10, and add the binary to
> the tree. Then 10 revisions later, you build again. Now say _someone
> else_ wants to go back and run the program as existed in r10. THEY CANT
> because they will get the binary from r20!
You are right this doesn't help with all cases. Though you could rename the
binary or put them each in a folder with the revision number to keep them
separate. Wouldn't it be better to have at least the latest binary in there
then nothing at all? ( if you cant remove the files regularly( easily ) and
don't have space for each change then you cant include them at all... ) As a
note this would not stop anybody from versioning all the files including the
binaries, it is only giving the people who maintain/use the repo more
options to choose from.
Re: Unversioned files held by repo
Posted by Matt imMute Sickler <im...@msk4.ath.cx>.
Mad Scientist wrote:
>
>
> On Wed, Mar 12, 2008 at 11:41 AM, Les Mikesell <lesmikesell@gmail.com
> <ma...@gmail.com>> wrote:
>
> Erik Huelsmann wrote:
> >
> > Subversion supports that model by not making more copies of a file
> > than necessary: all revisions for which a file is the same share
> > storage. So, for files which change infrequently, you shouldn't be
> > hesitant to store them in your repository.
>
> But... there are files that do change frequently and files where old
> instances have no use at all - and it would still be nice to be able to
> use subversions's access mechanisms to store and distribute them. And,
> of course, it would be nice to have a reasonable way to undo accidental
> commits of things that don't belong in the repository at all or can't
> remain for legal or political correctness reasons.
>
>
> As an example I am working on a project that requiers an expensive and
> proprietary compiler(not by choice) and as the only coder on the project
> currently I am the only one with who is able to compile the files need
> to use the program. I was disapointed when I found I could not keep a
> compiled binary with the revision I checked in which could later be
> removed as the repo size expanded and older binaries were no longer
> needed and free space declined. The folder layout is already set by a
> 3rd party and would work very well if unversioned files were able to be
> distributed with svn commit and svn update to the other people working
> on the project.
Here is exactly another case where "unversioned files" would be the ruin
of anyone using them. Suppose you build at r10, and add the binary to
the tree. Then 10 revisions later, you build again. Now say _someone
else_ wants to go back and run the program as existed in r10. THEY CANT
because they will get the binary from r20!
Subversion was designed not to lose history and does a damn good job of
it. If anyone *really really* wants this functionality, they are
welcome to submit patches to the source (assuming they manage to
actually write a decent patch considering how hard something as "simple"
as `svnadmin obliterate` is ).
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Mad Scientist <ma...@gmail.com>.
On Wed, Mar 12, 2008 at 11:41 AM, Les Mikesell <le...@gmail.com>
wrote:
> Erik Huelsmann wrote:
> >
> > Subversion supports that model by not making more copies of a file
> > than necessary: all revisions for which a file is the same share
> > storage. So, for files which change infrequently, you shouldn't be
> > hesitant to store them in your repository.
>
> But... there are files that do change frequently and files where old
> instances have no use at all - and it would still be nice to be able to
> use subversions's access mechanisms to store and distribute them. And,
> of course, it would be nice to have a reasonable way to undo accidental
> commits of things that don't belong in the repository at all or can't
> remain for legal or political correctness reasons.
As an example I am working on a project that requiers an expensive and
proprietary compiler(not by choice) and as the only coder on the project
currently I am the only one with who is able to compile the files need to
use the program. I was disapointed when I found I could not keep a compiled
binary with the revision I checked in which could later be removed as the
repo size expanded and older binaries were no longer needed and free space
declined. The folder layout is already set by a 3rd party and would work
very well if unversioned files were able to be distributed with svn commit
and svn update to the other people working on the project.
>
>
> --
> Les Mikesell
> lesmikesell@gmail.com
>
>
Re: Unversioned files held by repo
Posted by Les Mikesell <le...@gmail.com>.
Erik Huelsmann wrote:
>
> Subversion supports that model by not making more copies of a file
> than necessary: all revisions for which a file is the same share
> storage. So, for files which change infrequently, you shouldn't be
> hesitant to store them in your repository.
But... there are files that do change frequently and files where old
instances have no use at all - and it would still be nice to be able to
use subversions's access mechanisms to store and distribute them. And,
of course, it would be nice to have a reasonable way to undo accidental
commits of things that don't belong in the repository at all or can't
remain for legal or political correctness reasons.
--
Les Mikesell
lesmikesell@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Erik Huelsmann <eh...@gmail.com>.
On 3/12/08, Mad Scientist <ma...@gmail.com> wrote:
>
>
> On Wed, Mar 12, 2008 at 6:23 AM, Andy Levy <an...@gmail.com> wrote:
> >
> > On Wed, Mar 12, 2008 at 1:29 AM, Mad Scientist
> > <ma...@gmail.com> wrote:
> > > Hi, I am looking to submit a feature request for unversioned files
> > > stored in the repository along with normal versioned files. This could
> > > be beneficial for files such as project licenses which apply to all
> > > revisions
> >
> > Why would these need to be unversioned but in the repository? Put them
> > in normally, and if they never change, how is it different from
> > keeping them in the repo, unversioned?
>
> The benefit would be when the files do need to be changed and applied to
> previous revisions ( eg a license that covers all files in the repository )
> you are able to change them on every revision( from the view of a working
> copy ) instead of just changing the latest revision. As a note I was
> thinking for the repository to store the files not by updating past
> revisions but by having either a special revision number, -1 for instance,
> or saved in another form as an overlay to the checked out revision.
Where I come from, licences generally can't be backdated. If you
released a file under a certain license in October and then change the
license in December, than old license will have applied from October
to December. If you end up in court over what someone did in November,
the October license applies, no matter if you overwrote it with a new
version in December.
Subversion supports that model by not making more copies of a file
than necessary: all revisions for which a file is the same share
storage. So, for files which change infrequently, you shouldn't be
hesitant to store them in your repository.
Bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: http/ftp links in svn:externals (was: Re: Unversioned files
held by repo)
Posted by Matthew Hannigan <ml...@zip.com.au>.
On Wed, Mar 12, 2008 at 02:17:25PM -0500, Ryan Schmidt wrote:
>
> On Mar 12, 2008, at 10:43, Mad Scientist wrote:
>
>> As another option could be adjusting svn:external to work with http/ftp
>> links to external files. Which could offer much of the functionality of
>> unversioned files in the repository while being simpler to implement but
>> could have its own problems if a repository is moved or the site goes
>> down/moved.
>
> That's... an interesting suggestion...
>
> Of course you have to replace "links to external files" with "links to
> external directories" since externals work on the file level, not the
> directory level; there's an existing enhancement request about that:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=937
>
> Could be a bit tricky, since externals of course already support http links
> when that link is within a repository...
>
> Also even trickier because http URLs may not offer a directory listing, or
> if they do, the format is not predictable. That might be a show-stopper.
> Might have to wait for #937 to be implemented, and then restrict
> non-repository http links to single files, before this can be considered.
This requirement would probably be covered by Robert Collins' "config-manager"
It's in debian, but you can go to the source
The description is: "manage directories with Arch, CVS, HTTP, FTP and/or Subversion"
but I believe it does other vcs' including bzr.
The idea is that you place definitiions of dirs in a config file (e.g. get r1200 or HEAD
of a particular svn repo (or other vcs), and config-manager will fetch them.
It looks a little unmaintained; I'll try and get an update on it's rewrite to python.
http://www.robertcollins.net/config-manager.html
http://packages.debian.org/sid/config-manager
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: http/ftp links in svn:externals (was: Re: Unversioned files held by repo)
Posted by Lasse Vågsæther Karlsen <la...@vkarlsen.no>.
Just to be 100% sure, I tested it, and the external gets HEAD unless pegged.
On Wed, Mar 12, 2008 at 9:59 PM, Lasse Vågsæther Karlsen <la...@vkarlsen.no>
wrote:
> Question about externals for this "unversioned files" discussion.
>
> If I in revision 10 of my project add an external reference to another
> directory on the same server, in the same repository, and then keep that
> external there for the rest of my projects life, then... if I now, on
> revision 100+ go back and do a checkout of a previous copy (after revision
> 10) of my project to a new directory, does the revision of the files in the
> external working copy match the revision of my project working copy or will
> it pick HEAD?
>
> In other words...
>
> / <-- my project, mapped to svn://server/main
> /lib <-- external, mapped to /svn/server/lib
>
> if I change and commit files in main up to version 100, and sometimes
> update files in lib as well, let's say for simplicity that the lib was
> created for revision 10, and changed at revision 50 and 100.
>
> If I checkout a HEAD working copy today, of revision 110, to a directory,
> I would get:
>
> / <-- svn://server/main@110
> /lib <-- svn://server/lib@110
>
> however, what about going back and checking out, say, revision 25?
>
> / <-- svn://server/main@25
> /lib <-- svn://server/lib@25 or 110?
>
> if the external would get the HEAD revision, unless pegged, wouldn't this
> match what the original poster want, albeit not exactly as smooth as he
> wants it, if I understand him correctly?
>
> Or perhaps I'm wrong, and it will get revision 25...
> If so, then the question begs itself, what if the external is to another
> server where I have no control? I would assume it could only, as a rule,
> pick whatever is there at the moment, since it had no idea what was there at
> the time...
>
>
> On Wed, Mar 12, 2008 at 8:17 PM, Ryan Schmidt <
> subversion-2008a@ryandesign.com> wrote:
>
> >
> > On Mar 12, 2008, at 10:43, Mad Scientist wrote:
> >
> > > As another option could be adjusting svn:external to work with http/
> > > ftp links to external files. Which could offer much of the
> > > functionality of unversioned files in the repository while being
> > > simpler to implement but could have its own problems if a
> > > repository is moved or the site goes down/moved.
> >
> > That's... an interesting suggestion...
> >
> > Of course you have to replace "links to external files" with "links
> > to external directories" since externals work on the file level, not
> > the directory level; there's an existing enhancement request about that:
> >
> > http://subversion.tigris.org/issues/show_bug.cgi?id=937
> >
> > Could be a bit tricky, since externals of course already support http
> > links when that link is within a repository...
> >
> > Also even trickier because http URLs may not offer a directory
> > listing, or if they do, the format is not predictable. That might be
> > a show-stopper. Might have to wait for #937 to be implemented, and
> > then restrict non-repository http links to single files, before this
> > can be considered.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
>
> --
> Lasse Vågsæther Karlsen
> mailto:lasse@vkarlsen.no
> http://presentationmode.blogspot.com/
> PGP KeyID: 0xBCDEA2E3
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
Re: http/ftp links in svn:externals (was: Re: Unversioned files held by repo)
Posted by Lasse Vågsæther Karlsen <la...@vkarlsen.no>.
Question about externals for this "unversioned files" discussion.
If I in revision 10 of my project add an external reference to another
directory on the same server, in the same repository, and then keep that
external there for the rest of my projects life, then... if I now, on
revision 100+ go back and do a checkout of a previous copy (after revision
10) of my project to a new directory, does the revision of the files in the
external working copy match the revision of my project working copy or will
it pick HEAD?
In other words...
/ <-- my project, mapped to svn://server/main
/lib <-- external, mapped to /svn/server/lib
if I change and commit files in main up to version 100, and sometimes update
files in lib as well, let's say for simplicity that the lib was created for
revision 10, and changed at revision 50 and 100.
If I checkout a HEAD working copy today, of revision 110, to a directory, I
would get:
/ <-- svn://server/main@110
/lib <-- svn://server/lib@110
however, what about going back and checking out, say, revision 25?
/ <-- svn://server/main@25
/lib <-- svn://server/lib@25 or 110?
if the external would get the HEAD revision, unless pegged, wouldn't this
match what the original poster want, albeit not exactly as smooth as he
wants it, if I understand him correctly?
Or perhaps I'm wrong, and it will get revision 25...
If so, then the question begs itself, what if the external is to another
server where I have no control? I would assume it could only, as a rule,
pick whatever is there at the moment, since it had no idea what was there at
the time...
On Wed, Mar 12, 2008 at 8:17 PM, Ryan Schmidt <
subversion-2008a@ryandesign.com> wrote:
>
> On Mar 12, 2008, at 10:43, Mad Scientist wrote:
>
> > As another option could be adjusting svn:external to work with http/
> > ftp links to external files. Which could offer much of the
> > functionality of unversioned files in the repository while being
> > simpler to implement but could have its own problems if a
> > repository is moved or the site goes down/moved.
>
> That's... an interesting suggestion...
>
> Of course you have to replace "links to external files" with "links
> to external directories" since externals work on the file level, not
> the directory level; there's an existing enhancement request about that:
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=937
>
> Could be a bit tricky, since externals of course already support http
> links when that link is within a repository...
>
> Also even trickier because http URLs may not offer a directory
> listing, or if they do, the format is not predictable. That might be
> a show-stopper. Might have to wait for #937 to be implemented, and
> then restrict non-repository http links to single files, before this
> can be considered.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Lasse Vågsæther Karlsen
mailto:lasse@vkarlsen.no
http://presentationmode.blogspot.com/
PGP KeyID: 0xBCDEA2E3
Re: http/ftp links in svn:externals (was: Re: Unversioned files held by repo)
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Mar 12, 2008, at 10:43, Mad Scientist wrote:
> As another option could be adjusting svn:external to work with http/
> ftp links to external files. Which could offer much of the
> functionality of unversioned files in the repository while being
> simpler to implement but could have its own problems if a
> repository is moved or the site goes down/moved.
That's... an interesting suggestion...
Of course you have to replace "links to external files" with "links
to external directories" since externals work on the file level, not
the directory level; there's an existing enhancement request about that:
http://subversion.tigris.org/issues/show_bug.cgi?id=937
Could be a bit tricky, since externals of course already support http
links when that link is within a repository...
Also even trickier because http URLs may not offer a directory
listing, or if they do, the format is not predictable. That might be
a show-stopper. Might have to wait for #937 to be implemented, and
then restrict non-repository http links to single files, before this
can be considered.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Unversioned files held by repo
Posted by Mad Scientist <ma...@gmail.com>.
On Wed, Mar 12, 2008 at 6:23 AM, Andy Levy <an...@gmail.com> wrote:
> On Wed, Mar 12, 2008 at 1:29 AM, Mad Scientist
> <ma...@gmail.com> wrote:
> > Hi, I am looking to submit a feature request for unversioned files
> > stored in the repository along with normal versioned files. This could
> > be beneficial for files such as project licenses which apply to all
> > revisions
>
> Why would these need to be unversioned but in the repository? Put them
> in normally, and if they never change, how is it different from
> keeping them in the repo, unversioned?
The benefit would be when the files do need to be changed and applied to
previous revisions ( eg a license that covers all files in the repository )
you are able to change them on every revision( from the view of a working
copy ) instead of just changing the latest revision. As a note I was
thinking for the repository to store the files not by updating past
revisions but by having either a special revision number, -1 for instance,
or saved in another form as an overlay to the checked out revision.
>
>
> > or the latest generated files for people who do not want or
> > are unable to compile/build the files themselves.
>
> Have your build manager put them into a "release" tag which no one
> else is allowed to commit to, or place the items on a fileserver.
>
> > It keeps could also
> > keep the generated files in an easy to remove format when they become
> > out dated or space becomes an issue.
>
> This would require a very large change to Subversion - basically,
> you're asking for "svn obliterate" here, which I think is under
> consideration but involves a very large amount of work.
I was thinking this could be more of a side effect of a collision between a
file in the repository and overlay where the revisioned item gets
overwritten in the working copy. Though as you allude to below it could get
messy with at least one problem being important files unintentionally
covered up by an unversioned file.
>
> > I was thinking maybe these files
> > could be stored internally ( just a guess/suggestion ) at revision 0 or
> > -1 and override any versioned files.( could allow misplaced files to be
> > 'removed' as a quick patch until the repository is fixed, confidential
> > data on a public repository for instance )
>
> This sounds like it could get real messy and provide the potential for
> work to be lost.
As another option could be adjusting svn:external to work with http/ftp
links to external files. Which could offer much of the functionality of
unversioned files in the repository while being simpler to implement but
could have its own problems if a repository is moved or the site goes
down/moved.
Re: Unversioned files held by repo
Posted by Andy Levy <an...@gmail.com>.
On Wed, Mar 12, 2008 at 1:29 AM, Mad Scientist
<ma...@gmail.com> wrote:
> Hi, I am looking to submit a feature request for unversioned files
> stored in the repository along with normal versioned files. This could
> be beneficial for files such as project licenses which apply to all
> revisions
Why would these need to be unversioned but in the repository? Put them
in normally, and if they never change, how is it different from
keeping them in the repo, unversioned?
> or the latest generated files for people who do not want or
> are unable to compile/build the files themselves.
Have your build manager put them into a "release" tag which no one
else is allowed to commit to, or place the items on a fileserver.
> It keeps could also
> keep the generated files in an easy to remove format when they become
> out dated or space becomes an issue.
This would require a very large change to Subversion - basically,
you're asking for "svn obliterate" here, which I think is under
consideration but involves a very large amount of work.
> I was thinking maybe these files
> could be stored internally ( just a guess/suggestion ) at revision 0 or
> -1 and override any versioned files.( could allow misplaced files to be
> 'removed' as a quick patch until the repository is fixed, confidential
> data on a public repository for instance )
This sounds like it could get real messy and provide the potential for
work to be lost.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org