Medium-term roadmap: 1.3, 1.4, 1.5.

[Mark Grosberg <ma...@gladesoft.com>]

David Summers writes:

> Personally, I would rank them:
>
> 1.3 Atomic Renames
>
> 1.4 Server->Client configuration transmission
>
> 1.5 Operation Logging

I would agree that atomic renames is probably the most important feature 
to get out the door next. Do you think Server->Client configuration 
transmission might be easier to do after operation logging is in place? 
The reason why is that I think the server may need to know what the client 
is up to in order to send down the right configuration...

Thanks,
Mark G.


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

RE: Re: Medium-term roadmap: 1.3, 1.4, 1.5.

["Leeuw van der, Tim" <ti...@nl.unisys.com>]

I'm afraid that for compatibility-reasons, this has to be a long-term goal (ie, not before 2.0)
 
cheers,
 
--Tim

________________________________

Van: Karol Szkudlarek [mailto:karol@mikronika.com.pl]
Verzonden: ma 25-4-2005 15:48
Aan: Mark Grosberg
CC: dev@subversion.tigris.org
Onderwerp: Re: Medium-term roadmap: 1.3, 1.4, 1.5.



Hi!

I think that simplifying of .svn directory structure should be
interesting medium-term goal. Maybe instead of huge amount of
*.svn-base, *.svn-work files use one zipped file?

Greets,
Karol Szkudlarek



---------------------------------------------------------------------
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: Medium-term roadmap: 1.3, 1.4, 1.5.

[Karol Szkudlarek <ka...@mikronika.com.pl>]

Hi!

I think that simplifying of .svn directory structure should be
interesting medium-term goal. Maybe instead of huge amount of
*.svn-base, *.svn-work files use one zipped file?

Greets,
Karol Szkudlarek



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

Re: Medium-term roadmap: 1.3, 1.4, 1.5.

[Matthias Waechter <Ma...@tttech.com>]

Mark Grosberg <ma...@gladesoft.com> wrote on 22.04.2005 20:36:09:

> I would agree that atomic renames is probably the most important feature 

> to get out the door next.

IMHO, an additional important thing would be atomic delete+copy. Or atomic 
*whatever* to ensure consistent repository states. I mean, doing 
(re)structuring work on trunk/ for some operations requires multiple 
commits or server-side copies, even if using branches for preparation.

This is not limited to restructuring work, it is also required for local 
tagging.

Think of the following scenario: You have a /repos/libs/trunk/ directory 
that should be used in /repos/application/trunk/libs/, but this should not 
be accomplished via svn:externals but via local tagging for stability. 
This means you do a

        svn copy /repos/libs/trunk/ /repos/application/trunk/libs/

or maybe a

        svn copy /repos/libs/tags/stable_525/ 
/repos/application/trunk/libs/

once (locally or server-side) so that application/trunk/ remains stable 
independent from work done on libs/trunk/. If one wants a new version of 
libs/trunk/ in application/trunk/, he can either "svn merge" the changes 
or simply (and more cleanly) delete the old application/trunk/libs/ and 
copy the new version there. But this process cannot be accomplished as an 
atomic operation.

Note that merging is only usefull if the merged changes are small (no 
restructuring, not too infrequent) and the local version is under 
development. If no local modification is intended, delete+copy is far 
better than merging: Less repository overhead and cleaner repository 
operations since you do what you intend to do: delete the old 'tag' and 
copy a new one.

For example, deleting application/trunk/libs/ requires a transition from 
5->6, and copying libs/trunk/ to application/trunk/libs/ requires another 
transition from 6->7. Checking out at 6 brings up an inconsistent 
directory state. Not to mention what to do if this change should be 
reflected in application/trunk/README, this would be 7->8 if the copy 
operation was done as a server-side copy. So, count two inconsistent 
directory states. Don't mention what happens if it was not only 
application/trunk/libs/ but more directories like 
application/trunk/templates/ that would have to be "merged" atomically to 
the libs/ update.

- Matthias

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