You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark <cm...@yahoo.com> on 2002/08/22 13:25:24 UTC

Some svn workarea questions

Considering the current and planned functionality/features of subversion, is it
still possible to (the svn client can be on all 3 computers if needed):
    1) tar/zip a svn workarea on one computer and write it to CD
    2) untar/unzip it on a 2nd computer which has no access to the repository
    3) work on any/all files in that svn workarea on that 2nd computer
    4) move that modified svn workarea to a 3rd computer with access to the
repository and update/commit the changes? 

If still possible, is this workarea characteric of svn to be purposely
maintained? If not possible, what would prevent this?

Also, would there be any issues if a different OS account owned the svn
workarea on each of the 3 computers?

Thanks,

Mark


__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Some svn workarea questions

Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2002-08-22 at 09:25, Mark wrote:
>     1) tar/zip a svn workarea on one computer and write it to CD
>     2) untar/unzip it on a 2nd computer which has no access to the repository
>     3) work on any/all files in that svn workarea on that 2nd computer
>     4) move that modified svn workarea to a 3rd computer with access to the
> repository and update/commit the changes? 

As everyone else has said, sure.  Those are definitely goals.

> If still possible, is this workarea characteric of svn to be purposely
> maintained? If not possible, what would prevent this?

There is one idea which might affect this goal, but I don't know if it
will ever be implemented, it would be optional if it were implemented,
and it wouldn't cause a problem as long as you moved complete work areas
around.

The idea could be called "fast crawl."  First, we would have to have an
option to check out a working directory such that working files are
marked read-only until you do an explicit "svn edit" operation on them. 
(This has two immediate applications: advisory locks, and eliminating
the text-base and prop-base penalty on files which have not been edited
yet.)  Then, we could add a second option to allow fast crawl.  When you
do an "svn edit" of a file, Subversion would mark the containing
directory, and all of its parents, dirty.  Then, when we are crawling a
working area for changes, we only have to examine the dirty
directories.  (We can apply a similar concept to mixed-rev working
directories so that we don't have to scan the entire working area for
version divergences.)

The up side is that, for a very large projects like the *BSDs, status,
diff, checkin, and update operations would become much faster.  The down
sides are:

  * Aesthetically, it's displeasing for an svn command to have to modify
state in the parent directories of the directory it's in.

  * Working copy subdirs stop being completely portable.  If I move a
subdir of a working copy elsewhere, mess with it, and move it back, its
parent directories won't get marked dirty, so those changes would be
missed by a fast crawl.  But it would still be okay to move complete
working copies around, or to move working copy subdirs around as long as
you don't move them back.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Some svn workarea questions

Posted by Ben Collins-Sussman <su...@collab.net>.
Mark <cm...@yahoo.com> writes:

> Considering the current and planned functionality/features of subversion, is it
> still possible to (the svn client can be on all 3 computers if needed):
>     1) tar/zip a svn workarea on one computer and write it to CD
>     2) untar/unzip it on a 2nd computer which has no access to the repository
>     3) work on any/all files in that svn workarea on that 2nd computer
>     4) move that modified svn workarea to a 3rd computer with access to the
> repository and update/commit the changes? 

This should work just fine.  A working copy remembers the URL it came
from, but that's about it.


> Also, would there be any issues if a different OS account owned the svn
> workarea on each of the 3 computers?

The workarea caches the username/password;  but you can override that
with --username and --password switches.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Some svn workarea questions

Posted by cm...@collab.net.
Mark <cm...@yahoo.com> writes:

> Considering the current and planned functionality/features of subversion, is it
> still possible to (the svn client can be on all 3 computers if needed):
>     1) tar/zip a svn workarea on one computer and write it to CD
>     2) untar/unzip it on a 2nd computer which has no access to the repository
>     3) work on any/all files in that svn workarea on that 2nd computer
>     4) move that modified svn workarea to a 3rd computer with access to the
> repository and update/commit the changes? 

This should work so long as the original working copy referred to a
non-ambiguous URL (that is, *not* file:// or http://localhost/, for
example).

> If still possible, is this workarea characteric of svn to be purposely
> maintained? If not possible, what would prevent this?

Yes, purposely maintained.

> Also, would there be any issues if a different OS account owned the svn
> workarea on each of the 3 computers?

Subversion obeys regular OS permission rules -- it can only read/write
files that the OS says that its process's user has permission to toy
with.  Also, while Subversion defaults to using the current username
for authentication, this can be overridden by passing the --username
option to the program.  In other words, I can be 'cmpilato' on my
machine account, but commit against the repository as user
'rockstar'.  No sweat.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org