First, it should be noted that
sweep_all combines all available unspent outputs in the current account in a single transaction. Thus, your transaction may have a lot of inputs, which could be detrimental to your privacy if you received outputs that are close in proximity, i.e., from the same transaction or from multiple transactions in the same block.
Now, if you type
monero-wallet-cli and look at
sweep_all, it will show the following:
sweep_all [index=<N1>[,<N2>,...]] [<priority>] [<ring_size>] <address> [<payment_id>]
 indicates that the parameter is optional. Thus,
payment_id are all optional parameters, whereas
address is a mandatory parameter. Let's discuss all these parameters separately.
The index parameter can take any argument as long as it's an (unsigned) integer that corresponds to a primary address or subaddress that possesses a balance. For example, let's say your current account has three subaddresses all possessing a balance of 0.1 XMR and a main / primary address possessing a balance of 0.5 XMR. If you use
sweep_all index=1,2 <address>, it will only spend the 0.1 XMR of subaddress A and the 0.1 XMR of subaddress B for a combined 0.2 XMR. Similarly, if you use
sweep_all index=0,3 <address> it will only spend the 0.5 XMR of the main / primary address and the 0.1 XMR of subaddresses C for a combined 0.6 XMR. If this parameter is omitted,
sweep_all will use all available unspent outputs within the account.
The priority parameter has four available arguments, namely
monero-wallet-cli, the corresponding arguments to the priority parameter can only be passed as string. Put differently, you cannot specify them as (unsigned) integer. In addition, the default will be used if this parameter is omitted. More specifically, by default, the wallet will use the
unimportant level if there's low traffic on the network, whereas it will use the
normal level if there's considerable traffic on the network. Considerable traffic is defined as 80% of the last blocks being full and the mempool not containing a backlog. Lastly, note that any argument specified by the
set priority command (e.g.
set priority 1) will override this default behavior.
The ring size parameter can take any argument as long as it's an (unsigned) integer that is equal to or greater than 7 (the current minimum ring size enforced on the protocol level). The default of 7 will be used if this parameter is omitted.
The address parameter can take a standard / plain address, a subaddress, or an integrated address as argument. Address is a mandatory parameter and thus cannot be omitted.
The payment ID parameter can either take a short, encrypted 8-byte (16 hexadecimal characters) payment ID or a long, unencrypted 32-byte (64 hexadecimal characters) payment ID as argument. Two things to note. First, reusing a long, unencrypted payment ID will result in your transactions (that use the same payment ID) being linkable. Second, an integrated address is basically the result of embedding the short, encrypted payment-ID in the plain / standard address. Therefore, separately specifying the short, encrypted payment ID when sending to an integrated address is redundant and may even result in an error. Lastly, no payment ID will be attached to the
sweep_all transaction if the payment ID parameter is omitted.
As a practical example, let's say you want to send an unimportant
sweep_all transaction from the main / primary address (within the account) using ring size 10 to the general dev fund with a long, unencrypted payment ID attached (we'll use
1234567890123456789012345678901234567890123456789012345678901234 for this example). The command would then be:
sweep_all index=0 unimportant 10 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A 1234567890123456789012345678901234567890123456789012345678901234